AuroraMiddleware/qt5base-lts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
2e6ca4bbc3
qt5base-lts/cmake/QtPostProcess.cmake

655 lines
26 KiB
CMake
Raw Normal View History

CMake: Add MODULE_INCLUDE_NAME one-value-keyword to qt_add_module This value is the equivalent of qt_module.prf's MODULE_INCNAME and can be used to specify a name for the module's include subdirectory. The default is Qt<ModuleName>. The include name is stored in the module's target property MODULE_INCLUDE_NAME. Change-Id: Ie6c8f6882ee2c3db78884ae5781593c803be3c05 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-05-15 09:37:08 +00:00
function(qt_internal_write_depends_file module)
CMake: Fix build with custom INSTALL_INCLUDEDIR The include directory in Qt's build directory is always named "include", no matter what the value of INSTALL_INCLUDEDIR is. The main reason is that the name "include" is hard-coded in syncqt. The INSTALL_INCLUDEDIR variable must only affect the installation location of headers. Fixes: QTBUG-85893 Change-Id: I5367bc589cba129eb41817e2b58d470f730bb5ac Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-08-06 07:56:58 +00:00
set(outfile "${QT_BUILD_DIR}/include/${module}/${module}Depends")
Begin port of qtbase to CMake Done-by: Alexandru Croitor <alexandru.croitor@qt.io> Done-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Done-by: Kevin Funk <kevin.funk@kdab.com> Done-by: Mikhail Svetkin <mikhail.svetkin@qt.io> Done-by: Simon Hausmann <simon.hausmann@qt.io> Done-by: Tobias Hunger <tobias.hunger@qt.io> Done-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Done-by: Volker Krause <volker.krause@kdab.com> Change-Id: Ida4f8bd190f9a4849a1af7b5b7981337a5df5310 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
2018-10-24 13:20:27 +00:00
set(contents "/* This file was generated by cmake with the info from ${module} target. */\n")
string(APPEND contents "#ifdef __cplusplus /* create empty PCH in C mode */\n")
foreach (m ${ARGN})
string(APPEND contents "# include <Qt${m}/Qt${m}>\n")
endforeach()
string(APPEND contents "#endif\n")
QtPostProcess: Fix generation of *Depends header files Normalize Qt module names before trying to match them. Deduplicate the names while at it. Change-Id: I5821c34fe5904cf9e9b986ac3ae4af2b248466b7 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2018-10-30 14:25:53 +00:00
file(GENERATE OUTPUT "${outfile}" CONTENT "${contents}")
Begin port of qtbase to CMake Done-by: Alexandru Croitor <alexandru.croitor@qt.io> Done-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Done-by: Kevin Funk <kevin.funk@kdab.com> Done-by: Mikhail Svetkin <mikhail.svetkin@qt.io> Done-by: Simon Hausmann <simon.hausmann@qt.io> Done-by: Tobias Hunger <tobias.hunger@qt.io> Done-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Done-by: Volker Krause <volker.krause@kdab.com> Change-Id: Ida4f8bd190f9a4849a1af7b5b7981337a5df5310 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
2018-10-24 13:20:27 +00:00
endfunction()
QtPostProcess: Check target link-type when collecting deps Fixes a configure issue in qtgamepad Change-Id: I8212d6d58fd2f28ae71a9559cf6544102a873718 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
2019-09-24 13:53:41 +00:00
macro(qt_collect_third_party_deps target)
set(_target_is_static OFF)
get_target_property(_target_type ${target} TYPE)
if (${_target_type} STREQUAL "STATIC_LIBRARY")
set(_target_is_static ON)
endif()
unset(_target_type)
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
# If we are doing a non-static Qt build, we only want to propagate public dependencies.
# If we are doing a static Qt build, we need to propagate all dependencies.
set(depends_var "public_depends")
QtPostProcess: Check target link-type when collecting deps Fixes a configure issue in qtgamepad Change-Id: I8212d6d58fd2f28ae71a9559cf6544102a873718 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
2019-09-24 13:53:41 +00:00
if(_target_is_static)
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
set(depends_var "depends")
endif()
QtPostProcess: Check target link-type when collecting deps Fixes a configure issue in qtgamepad Change-Id: I8212d6d58fd2f28ae71a9559cf6544102a873718 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
2019-09-24 13:53:41 +00:00
unset(_target_is_static)
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
foreach(dep ${${depends_var}})
# Gather third party packages that should be found when using the Qt module.
# Also handle nolink target dependencies.
string(REGEX REPLACE "_nolink$" "" base_dep "${dep}")
if(NOT base_dep STREQUAL dep)
# Resets target name like Vulkan_nolink to Vulkan, because we need to call
# find_package(Vulkan).
set(dep ${base_dep})
endif()
QtPostProcess: Fix generation of *Depends header files Normalize Qt module names before trying to match them. Deduplicate the names while at it. Change-Id: I5821c34fe5904cf9e9b986ac3ae4af2b248466b7 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2018-10-30 14:25:53 +00:00
CMake: Fix Threads::Threads dependency handling with CMake < 3.18 Apparently CMake encods targets from different scopes with a different encoding scheme for earlier CMake versions. CMake 3.16.3: Threads::Threads::@<0x5604cb3f6b50> CMake 3.18.0: ::@(0x5604cb3f6b50);Threads::Threads;::@ Handle the earlier version approach as well. It needs to be done both when writing out 3rd party dependencies, as well as for lib prl files. Possibly in more places as well, but I didn't detect additional places yet. Amends 92ee9bd6b885879090ba57e49c8bd84a06d42b2b Task-number: QTBUG-85801 Task-number: QTBUG-85877 Change-Id: Ib348b51b2d623fb50d9080dba2beeb931d47a69c Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-12 12:34:06 +00:00
# Strip any directory scope tokens.
qt_internal_strip_target_directory_scope_token("${dep}" dep)
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
if(TARGET ${dep})
list(FIND third_party_deps_seen ${dep} dep_seen)
Make module package depend on its own tool package Also make the tool package depend on all tool packages that correspond to the qt module dependencies. So find_package(Qt5Widgets) implicitly calls find_package(Qt5WidgetTools). And find_package(Qt5WidgetsTools) will call find_package for Qt5GuiTools, and Qt5CoreTools. This enhances the user experience, so that in modules like qtsvg, you don't have to specify both find_package(Qt5Widgets) and find_package(Qt5WidgetsTools), but only the former. Or when cross building, you only need to specify Qt5WidgetTools, to get both Core and Gui tools. Change-Id: Ib1c5173a5b97584a52e144c22e38e90a712f727a Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-04-29 12:36:25 +00:00
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
get_target_property(package_name ${dep} INTERFACE_QT_PACKAGE_NAME)
if(dep_seen EQUAL -1 AND package_name)
list(APPEND third_party_deps_seen ${dep})
get_target_property(package_version ${dep} INTERFACE_QT_PACKAGE_VERSION)
if(NOT package_version)
set(package_version "")
Make module package depend on its own tool package Also make the tool package depend on all tool packages that correspond to the qt module dependencies. So find_package(Qt5Widgets) implicitly calls find_package(Qt5WidgetTools). And find_package(Qt5WidgetsTools) will call find_package for Qt5GuiTools, and Qt5CoreTools. This enhances the user experience, so that in modules like qtsvg, you don't have to specify both find_package(Qt5Widgets) and find_package(Qt5WidgetsTools), but only the former. Or when cross building, you only need to specify Qt5WidgetTools, to get both Core and Gui tools. Change-Id: Ib1c5173a5b97584a52e144c22e38e90a712f727a Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-04-29 12:36:25 +00:00
endif()
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
get_target_property(package_components ${dep} INTERFACE_QT_PACKAGE_COMPONENTS)
if(NOT package_components)
set(package_components "")
endif()
list(APPEND third_party_deps
"${package_name}\;${package_version}\;${package_components}")
Begin port of qtbase to CMake Done-by: Alexandru Croitor <alexandru.croitor@qt.io> Done-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Done-by: Kevin Funk <kevin.funk@kdab.com> Done-by: Mikhail Svetkin <mikhail.svetkin@qt.io> Done-by: Simon Hausmann <simon.hausmann@qt.io> Done-by: Tobias Hunger <tobias.hunger@qt.io> Done-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Done-by: Volker Krause <volker.krause@kdab.com> Change-Id: Ida4f8bd190f9a4849a1af7b5b7981337a5df5310 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
2018-10-24 13:20:27 +00:00
endif()
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
endif()
endforeach()
endmacro()
function(qt_internal_create_module_depends_file target)
Add support for Qt header_modules aka a header only INTERFACE library Also add support for modules that have no private module counterpart. Both are needed for Designer's QtUiPlugin in qttools. Change-Id: Ia7e9d8837140e1de5cd59e196b4f63481ab68298 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Qt CMake Build Bot
2019-08-19 13:07:22 +00:00
get_target_property(target_type "${target}" TYPE)
if(target_type STREQUAL "INTERFACE_LIBRARY")
set(arg_HEADER_MODULE ON)
else()
set(arg_HEADER_MODULE OFF)
endif()
Only export public module link dependencies for shared builds Unless we are building under a static library configuration there is no reason to export the dependency on private libraries. Change-Id: I724da38495dc55cc2783d4b19c01533fc0900d22 Reviewed-by: Liang Qi <liang.qi@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-11 15:49:54 +00:00
set(depends "")
if(target_type STREQUAL "STATIC_LIBRARY" AND NOT arg_HEADER_MODULE)
Add support for Qt header_modules aka a header only INTERFACE library Also add support for modules that have no private module counterpart. Both are needed for Designer's QtUiPlugin in qttools. Change-Id: Ia7e9d8837140e1de5cd59e196b4f63481ab68298 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Qt CMake Build Bot
2019-08-19 13:07:22 +00:00
get_target_property(depends "${target}" LINK_LIBRARIES)
endif()
Only export public module link dependencies for shared builds Unless we are building under a static library configuration there is no reason to export the dependency on private libraries. Change-Id: I724da38495dc55cc2783d4b19c01533fc0900d22 Reviewed-by: Liang Qi <liang.qi@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-11 15:49:54 +00:00
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
get_target_property(public_depends "${target}" INTERFACE_LINK_LIBRARIES)
Add some clarifying documentation in QtPostProcess Specifically what each of the list variables in qt_internal_create_module_depends_file is used for. Change-Id: Ie4f8c0d7387308518932d37e802ecaeb0572b955 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Qt CMake Build Bot Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
2019-08-20 13:46:12 +00:00
# Used for collecting Qt module dependencies that should be find_package()'d in
# ModuleDependencies.cmake.
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
get_target_property(target_deps "${target}" _qt_target_deps)
set(target_deps_seen "")
CMake: Provide old style CMake variables for target info This change provides the following per-module variables Qt6Widgets_LIBRARIES, Qt6Widgets_INCLUDE_DIRS, Qt6Widgets_DEFINITIONS, Qt6Widgets_COMPILE_DEFINITIONS, Qt6Widgets_PRIVATE_INCLUDE_DIRS. These are deprecated and are only intended for easier porting from Qt5 to Qt6. Qt consumers should instead rely on the Qt module targets e.g target_link_libraries(app PRIVATE Qt6::Widgets) Note that the variable contents includes transitive values for everything except the _LIBRARIES variant. So Qt6Widgets_INCLUDE_DIRS will contain values for Widgets, Gui and Core. Qt6Widgets_LIBRARIES only contains a value like Qt6::Widgets, and when that is used in target_link_libraries(), CMake will take care of the transitivity. Change-Id: I625e25aab7ba5eaf14de1dc76ba2a1a0c85e6226 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-07-14 16:08:07 +00:00
set(qt_module_dependencies "")
QtPostProcess: Fix generation of *Depends header files Normalize Qt module names before trying to match them. Deduplicate the names while at it. Change-Id: I5821c34fe5904cf9e9b986ac3ae4af2b248466b7 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2018-10-30 14:25:53 +00:00
Add support for Qt header_modules aka a header only INTERFACE library Also add support for modules that have no private module counterpart. Both are needed for Designer's QtUiPlugin in qttools. Change-Id: Ia7e9d8837140e1de5cd59e196b4f63481ab68298 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Qt CMake Build Bot
2019-08-19 13:07:22 +00:00
if(NOT arg_HEADER_MODULE)
get_target_property(extra_depends "${target}" QT_EXTRA_PACKAGE_DEPENDENCIES)
endif()
Make WinMain linkage compatible with Qt 5 In Qt 5, the Qt5Core target was extended by Qt5CoreConfigExtras.cmake to have a generator expression as interface linkage that would conditionally link WinMain. This patch implements the same through regular interface linkage right in corelib. Since the linkage happens through a generator expression, our dependency generator does not see this as a dependency. Therefore we add this as an unconditional package dependency for corelib, on Windows. In theory this could be done also in winmain's CMakeLists.txt, as targets can be extended outside of their directory. However this adds a directory id (WinMain:@<023423>) to the linkage, which mysteriously is not removed on the exported core target. Change-Id: If2abb9ba790f51274f582c9ec28c13d968b84302 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
2019-06-12 11:09:13 +00:00
if(NOT extra_depends STREQUAL "${extra_depends}-NOTFOUND")
Provide a way to specify extra tool package dependencies In the qtwayland repo, both WaylandClient and WaylandCompositor packages need access to the qtwaylandscanner tool. That means that the add_qt_tool(qtwaylandscanner) can't use the TOOLS_TARGET argument to associate a dependency with only one of the above modules. Instead add_qt_tool now allows specifying a non-existent module name for the TOOLS_TARGET argument, which can be manually depended on by other packages. Actually, you could specify the non-existent module before as well, but that didn't do everything that had to be done. This required a bit of refactoring in how the Dependencies file for Tools packages is created. Now the file is created in qt_export_tools. Two new functions were also added to allow recording additional dependencies between packages. Also some bug fixes were done to make it all work. Specifically the _FOUND variable generated in the Dependencies file was incorrect. Also there are some quotes missing when appending extra package dependencies via the QT_EXTRA_PACKAGE_DEPENDENCIES property. Change-Id: I167efec16dff8d036e191df3572ea72764e22bc5 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-11-15 15:28:17 +00:00
list(APPEND target_deps "${extra_depends}")
Make WinMain linkage compatible with Qt 5 In Qt 5, the Qt5Core target was extended by Qt5CoreConfigExtras.cmake to have a generator expression as interface linkage that would conditionally link WinMain. This patch implements the same through regular interface linkage right in corelib. Since the linkage happens through a generator expression, our dependency generator does not see this as a dependency. Therefore we add this as an unconditional package dependency for corelib, on Windows. In theory this could be done also in winmain's CMakeLists.txt, as targets can be extended outside of their directory. However this adds a directory id (WinMain:@<023423>) to the linkage, which mysteriously is not removed on the exported core target. Change-Id: If2abb9ba790f51274f582c9ec28c13d968b84302 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
2019-06-12 11:09:13 +00:00
endif()
Add some clarifying documentation in QtPostProcess Specifically what each of the list variables in qt_internal_create_module_depends_file is used for. Change-Id: Ie4f8c0d7387308518932d37e802ecaeb0572b955 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Qt CMake Build Bot Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
2019-08-20 13:46:12 +00:00
# Used for assembling the content of an include/Module/ModuleDepends.h header.
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
set(qtdeps "")
Add some clarifying documentation in QtPostProcess Specifically what each of the list variables in qt_internal_create_module_depends_file is used for. Change-Id: Ie4f8c0d7387308518932d37e802ecaeb0572b955 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Qt CMake Build Bot Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
2019-08-20 13:46:12 +00:00
# Used for collecting third party dependencies that should be find_package()'d in
# ModuleDependencies.cmake.
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
set(third_party_deps "")
set(third_party_deps_seen "")
Add some clarifying documentation in QtPostProcess Specifically what each of the list variables in qt_internal_create_module_depends_file is used for. Change-Id: Ie4f8c0d7387308518932d37e802ecaeb0572b955 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Qt CMake Build Bot Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
2019-08-20 13:46:12 +00:00
# Used for collecting Qt tool dependencies that should be find_package()'d in
# ModuleToolsDependencies.cmake.
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
set(tool_deps "")
set(tool_deps_seen "")
Add some clarifying documentation in QtPostProcess Specifically what each of the list variables in qt_internal_create_module_depends_file is used for. Change-Id: Ie4f8c0d7387308518932d37e802ecaeb0572b955 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Qt CMake Build Bot Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
2019-08-20 13:46:12 +00:00
# Used for collecting Qt tool dependencies that should be find_package()'d in
# ModuleDependencies.cmake.
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
set(main_module_tool_deps "")
Abstract and fix usages of QT_KNOWN_MODULES In some places of the build system we need to iterate over repo specific Qt known modules (aka the ones that are built in the current project). In other places we need to iterate over the whole list of known Qt modules (those found via find_package + the ones built in the current project). Introduce two separate functions that provide access to either the former or latter, and adjust all existing usages of QT_KNOWN_MODULES as needed. Change-Id: Ica96d0cfe690b9aaaa3f8c53bc84975bccad69c7 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Qt CMake Build Bot Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
2019-08-20 13:24:14 +00:00
qt_internal_get_qt_all_known_modules(known_modules)
Fix creation of ModuleDepends header file with correct dependencies The content of the generated header files should reference both public and private Qt module dependencies. This is the same as what qmake does. Change-Id: I2e47c93291d677b86af7bb80fb788b2acf939743 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Qt CMake Build Bot
2019-08-20 13:44:34 +00:00
set(all_depends ${depends} ${public_depends})
foreach (dep ${all_depends})
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
# Normalize module by stripping leading "Qt::" and trailing "Private"
if (dep MATCHES "Qt::(.*)")
set(dep "${CMAKE_MATCH_1}")
Add QT_MODULE_SKIP_MODULE_INCLUDES property When a Qt module has this property set, when we generate the QtModuleDepends header file and find this module it will not be added. This is required to be able to create a Core_qobject module, as it does not have any headers. Change-Id: Iaea1080919d05ace12e48693e02d8c0f4c669339 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-05 13:28:15 +00:00
if (TARGET Qt::${dep})
get_target_property(dep_type Qt::${dep} TYPE)
if (NOT dep_type STREQUAL "INTERFACE_LIBRARY")
get_target_property(skip_module_depends_include Qt::${dep} QT_MODULE_SKIP_DEPENDS_INCLUDE)
if (skip_module_depends_include)
continue()
endif()
endif()
endif()
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
endif()
if (dep MATCHES "(.*)Private")
set(dep "${CMAKE_MATCH_1}")
Write find_dependency() calls in Qt Module config files This change introduces a new function called qt_find_package() which can take an extra option called PROVIDED_TARGETS, which associates targets with the package that defines those targets. This is done by setting the INTERFACE_QT_PACKAGE_NAME and INTERFACE_QT_PACKAGE_VERSION properties on the imported targets. This information allows us to generate appropriate find_dependency() calls in a module's Config file for third party libraries. For example when an application links against QtCore, it should also link against zlib and atomic libraries. In order to do that, the library locations first have to be found by CMake. This is achieved by embedding find_dependency(ZLIB) and find_dependency(Atomic) in Qt5CoreDependencies.cmake which is included by Qt5CoreConfig.cmake. The latter is picked up when an application project contains find_package(Qt5Core), and thus all linking dependencies are resolved. The information 'which package provides which targets' is contained in the python json2cmake conversion script. The generated output of the script contains qt_find_package() calls that represent that information. The Qt5CoreDependencies.cmake file and which which dependencies it contains is generated at the QtPostProcess stop. Note that for non-static Qt builds, we only need to propagate public 3rd party libraries. For static builds, we need all third party libraries. In order for the INTERFACE_QT_PACKAGE_NAME property to be read in any scope, the targets on which the property is set, have to be GLOBAL. Also for applications and other modules to find all required third party libraries, we have to install all our custom Find modules, and make sure they define INTERFACE IMPORTED libraries, and not just IMPORTED libraries. Change-Id: I694d6e32d05b96d5e241df0156fc79d0029426aa Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-04-24 15:14:25 +00:00
endif()
Abstract and fix usages of QT_KNOWN_MODULES In some places of the build system we need to iterate over repo specific Qt known modules (aka the ones that are built in the current project). In other places we need to iterate over the whole list of known Qt modules (those found via find_package + the ones built in the current project). Introduce two separate functions that provide access to either the former or latter, and adjust all existing usages of QT_KNOWN_MODULES as needed. Change-Id: Ica96d0cfe690b9aaaa3f8c53bc84975bccad69c7 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Qt CMake Build Bot Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
2019-08-20 13:24:14 +00:00
list(FIND known_modules "${dep}" _pos)
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
if (_pos GREATER -1)
list(APPEND qtdeps "${dep}")
Handle generating find_dependency() calls for nolink targets Previously we just recorded that Gui has to link against Vulkan::Vulkan_nolink, but if an application consumed Gui, it wouldn't find that target. We need to record that if a module links against Vulkan_nolink, and then generate a find_dependency(Vulkan) call in the module config file. We also have to assign the _nolink interface library to an export (the Qt5 one), so that it gets installed as a target. Change-Id: Icbc29ff4161ab18fdd162196ae128e29c1ee8c80 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 13:21:30 +00:00
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
# Make the ModuleTool package depend on dep's ModuleTool package.
list(FIND tool_deps_seen ${dep} dep_seen)
if(dep_seen EQUAL -1 AND ${dep} IN_LIST QT_KNOWN_MODULES_WITH_TOOLS)
list(APPEND tool_deps_seen ${dep})
list(APPEND tool_deps
"${INSTALL_CMAKE_NAMESPACE}${dep}Tools\;${PROJECT_VERSION}")
endif()
endif()
endforeach()
Write find_dependency() calls in Qt Module config files This change introduces a new function called qt_find_package() which can take an extra option called PROVIDED_TARGETS, which associates targets with the package that defines those targets. This is done by setting the INTERFACE_QT_PACKAGE_NAME and INTERFACE_QT_PACKAGE_VERSION properties on the imported targets. This information allows us to generate appropriate find_dependency() calls in a module's Config file for third party libraries. For example when an application links against QtCore, it should also link against zlib and atomic libraries. In order to do that, the library locations first have to be found by CMake. This is achieved by embedding find_dependency(ZLIB) and find_dependency(Atomic) in Qt5CoreDependencies.cmake which is included by Qt5CoreConfig.cmake. The latter is picked up when an application project contains find_package(Qt5Core), and thus all linking dependencies are resolved. The information 'which package provides which targets' is contained in the python json2cmake conversion script. The generated output of the script contains qt_find_package() calls that represent that information. The Qt5CoreDependencies.cmake file and which which dependencies it contains is generated at the QtPostProcess stop. Note that for non-static Qt builds, we only need to propagate public 3rd party libraries. For static builds, we need all third party libraries. In order for the INTERFACE_QT_PACKAGE_NAME property to be read in any scope, the targets on which the property is set, have to be GLOBAL. Also for applications and other modules to find all required third party libraries, we have to install all our custom Find modules, and make sure they define INTERFACE IMPORTED libraries, and not just IMPORTED libraries. Change-Id: I694d6e32d05b96d5e241df0156fc79d0029426aa Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-04-24 15:14:25 +00:00
QtPostProcess: Check target link-type when collecting deps Fixes a configure issue in qtgamepad Change-Id: I8212d6d58fd2f28ae71a9559cf6544102a873718 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
2019-09-24 13:53:41 +00:00
qt_collect_third_party_deps(${target})
Write find_dependency() calls in Qt Module config files This change introduces a new function called qt_find_package() which can take an extra option called PROVIDED_TARGETS, which associates targets with the package that defines those targets. This is done by setting the INTERFACE_QT_PACKAGE_NAME and INTERFACE_QT_PACKAGE_VERSION properties on the imported targets. This information allows us to generate appropriate find_dependency() calls in a module's Config file for third party libraries. For example when an application links against QtCore, it should also link against zlib and atomic libraries. In order to do that, the library locations first have to be found by CMake. This is achieved by embedding find_dependency(ZLIB) and find_dependency(Atomic) in Qt5CoreDependencies.cmake which is included by Qt5CoreConfig.cmake. The latter is picked up when an application project contains find_package(Qt5Core), and thus all linking dependencies are resolved. The information 'which package provides which targets' is contained in the python json2cmake conversion script. The generated output of the script contains qt_find_package() calls that represent that information. The Qt5CoreDependencies.cmake file and which which dependencies it contains is generated at the QtPostProcess stop. Note that for non-static Qt builds, we only need to propagate public 3rd party libraries. For static builds, we need all third party libraries. In order for the INTERFACE_QT_PACKAGE_NAME property to be read in any scope, the targets on which the property is set, have to be GLOBAL. Also for applications and other modules to find all required third party libraries, we have to install all our custom Find modules, and make sure they define INTERFACE IMPORTED libraries, and not just IMPORTED libraries. Change-Id: I694d6e32d05b96d5e241df0156fc79d0029426aa Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-04-24 15:14:25 +00:00
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
# Add dependency to the main ModuleTool package to ModuleDependencies file.
if(${target} IN_LIST QT_KNOWN_MODULES_WITH_TOOLS)
set(main_module_tool_deps
"${INSTALL_CMAKE_NAMESPACE}${target}Tools\;${PROJECT_VERSION}")
endif()
Write find_dependency() calls in Qt Module config files This change introduces a new function called qt_find_package() which can take an extra option called PROVIDED_TARGETS, which associates targets with the package that defines those targets. This is done by setting the INTERFACE_QT_PACKAGE_NAME and INTERFACE_QT_PACKAGE_VERSION properties on the imported targets. This information allows us to generate appropriate find_dependency() calls in a module's Config file for third party libraries. For example when an application links against QtCore, it should also link against zlib and atomic libraries. In order to do that, the library locations first have to be found by CMake. This is achieved by embedding find_dependency(ZLIB) and find_dependency(Atomic) in Qt5CoreDependencies.cmake which is included by Qt5CoreConfig.cmake. The latter is picked up when an application project contains find_package(Qt5Core), and thus all linking dependencies are resolved. The information 'which package provides which targets' is contained in the python json2cmake conversion script. The generated output of the script contains qt_find_package() calls that represent that information. The Qt5CoreDependencies.cmake file and which which dependencies it contains is generated at the QtPostProcess stop. Note that for non-static Qt builds, we only need to propagate public 3rd party libraries. For static builds, we need all third party libraries. In order for the INTERFACE_QT_PACKAGE_NAME property to be read in any scope, the targets on which the property is set, have to be GLOBAL. Also for applications and other modules to find all required third party libraries, we have to install all our custom Find modules, and make sure they define INTERFACE IMPORTED libraries, and not just IMPORTED libraries. Change-Id: I694d6e32d05b96d5e241df0156fc79d0029426aa Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-04-24 15:14:25 +00:00
CMake: Fix old style find_package(Qt6Foo) to work Each module package needs to first find the Qt6 package to ensure that all the necessary info is setup for further depedencies to be found. Task-number: QTBUG-81672 Change-Id: I3ee608d24c1efbb63a063261fb36341bf52fb78d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-07-14 09:25:47 +00:00
# Dirty deduplication hack because of https://gitlab.kitware.com/cmake/cmake/issues/19200
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
foreach(dep ${target_deps})
if(dep)
list(FIND target_deps_seen "${dep}" dep_seen)
if(dep_seen EQUAL -1)
list(LENGTH dep len)
if(NOT (len EQUAL 2))
message(FATAL_ERROR "List '${dep}' should look like QtFoo;version")
Write find_dependency() calls in Qt Module config files This change introduces a new function called qt_find_package() which can take an extra option called PROVIDED_TARGETS, which associates targets with the package that defines those targets. This is done by setting the INTERFACE_QT_PACKAGE_NAME and INTERFACE_QT_PACKAGE_VERSION properties on the imported targets. This information allows us to generate appropriate find_dependency() calls in a module's Config file for third party libraries. For example when an application links against QtCore, it should also link against zlib and atomic libraries. In order to do that, the library locations first have to be found by CMake. This is achieved by embedding find_dependency(ZLIB) and find_dependency(Atomic) in Qt5CoreDependencies.cmake which is included by Qt5CoreConfig.cmake. The latter is picked up when an application project contains find_package(Qt5Core), and thus all linking dependencies are resolved. The information 'which package provides which targets' is contained in the python json2cmake conversion script. The generated output of the script contains qt_find_package() calls that represent that information. The Qt5CoreDependencies.cmake file and which which dependencies it contains is generated at the QtPostProcess stop. Note that for non-static Qt builds, we only need to propagate public 3rd party libraries. For static builds, we need all third party libraries. In order for the INTERFACE_QT_PACKAGE_NAME property to be read in any scope, the targets on which the property is set, have to be GLOBAL. Also for applications and other modules to find all required third party libraries, we have to install all our custom Find modules, and make sure they define INTERFACE IMPORTED libraries, and not just IMPORTED libraries. Change-Id: I694d6e32d05b96d5e241df0156fc79d0029426aa Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-04-24 15:14:25 +00:00
endif()
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
list(GET dep 0 dep_name)
list(GET dep 1 dep_ver)
Write find_dependency() calls in Qt Module config files This change introduces a new function called qt_find_package() which can take an extra option called PROVIDED_TARGETS, which associates targets with the package that defines those targets. This is done by setting the INTERFACE_QT_PACKAGE_NAME and INTERFACE_QT_PACKAGE_VERSION properties on the imported targets. This information allows us to generate appropriate find_dependency() calls in a module's Config file for third party libraries. For example when an application links against QtCore, it should also link against zlib and atomic libraries. In order to do that, the library locations first have to be found by CMake. This is achieved by embedding find_dependency(ZLIB) and find_dependency(Atomic) in Qt5CoreDependencies.cmake which is included by Qt5CoreConfig.cmake. The latter is picked up when an application project contains find_package(Qt5Core), and thus all linking dependencies are resolved. The information 'which package provides which targets' is contained in the python json2cmake conversion script. The generated output of the script contains qt_find_package() calls that represent that information. The Qt5CoreDependencies.cmake file and which which dependencies it contains is generated at the QtPostProcess stop. Note that for non-static Qt builds, we only need to propagate public 3rd party libraries. For static builds, we need all third party libraries. In order for the INTERFACE_QT_PACKAGE_NAME property to be read in any scope, the targets on which the property is set, have to be GLOBAL. Also for applications and other modules to find all required third party libraries, we have to install all our custom Find modules, and make sure they define INTERFACE IMPORTED libraries, and not just IMPORTED libraries. Change-Id: I694d6e32d05b96d5e241df0156fc79d0029426aa Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-04-24 15:14:25 +00:00
CMake: Fix old style find_package(Qt6Foo) to work Each module package needs to first find the Qt6 package to ensure that all the necessary info is setup for further depedencies to be found. Task-number: QTBUG-81672 Change-Id: I3ee608d24c1efbb63a063261fb36341bf52fb78d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-07-14 09:25:47 +00:00
# Skip over Qt6 dependency, because we will manually handle it in the Dependencies
# file before everything else, to ensure that find_package(Qt6Core)-style works.
if(dep_name STREQUAL INSTALL_CMAKE_NAMESPACE)
continue()
endif()
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
list(APPEND target_deps_seen "${dep_name}\;${dep_ver}")
CMake: Provide old style CMake variables for target info This change provides the following per-module variables Qt6Widgets_LIBRARIES, Qt6Widgets_INCLUDE_DIRS, Qt6Widgets_DEFINITIONS, Qt6Widgets_COMPILE_DEFINITIONS, Qt6Widgets_PRIVATE_INCLUDE_DIRS. These are deprecated and are only intended for easier porting from Qt5 to Qt6. Qt consumers should instead rely on the Qt module targets e.g target_link_libraries(app PRIVATE Qt6::Widgets) Note that the variable contents includes transitive values for everything except the _LIBRARIES variant. So Qt6Widgets_INCLUDE_DIRS will contain values for Widgets, Gui and Core. Qt6Widgets_LIBRARIES only contains a value like Qt6::Widgets, and when that is used in target_link_libraries(), CMake will take care of the transitivity. Change-Id: I625e25aab7ba5eaf14de1dc76ba2a1a0c85e6226 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-07-14 16:08:07 +00:00
if (dep_name MATCHES "${INSTALL_CMAKE_NAMESPACE}(.*)")
list(APPEND qt_module_dependencies "${CMAKE_MATCH_1}")
endif()
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
endif()
Make module package depend on its own tool package Also make the tool package depend on all tool packages that correspond to the qt module dependencies. So find_package(Qt5Widgets) implicitly calls find_package(Qt5WidgetTools). And find_package(Qt5WidgetsTools) will call find_package for Qt5GuiTools, and Qt5CoreTools. This enhances the user experience, so that in modules like qtsvg, you don't have to specify both find_package(Qt5Widgets) and find_package(Qt5WidgetsTools), but only the former. Or when cross building, you only need to specify Qt5WidgetTools, to get both Core and Gui tools. Change-Id: Ib1c5173a5b97584a52e144c22e38e90a712f727a Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-04-29 12:36:25 +00:00
endif()
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
endforeach()
set(target_deps "${target_deps_seen}")
if (DEFINED qtdeps)
list(REMOVE_DUPLICATES qtdeps)
endif()
Add support for Qt header_modules aka a header only INTERFACE library Also add support for modules that have no private module counterpart. Both are needed for Designer's QtUiPlugin in qttools. Change-Id: Ia7e9d8837140e1de5cd59e196b4f63481ab68298 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Qt CMake Build Bot
2019-08-19 13:07:22 +00:00
get_target_property(hasModuleHeaders "${target}" INTERFACE_MODULE_HAS_HEADERS)
Revert "CMake: Don't create *Depends header for header-only modules" This reverts commit e875f458055d6a7b54d2d853590ccc2495ab145b. Reason for revert: syncqt creates a master header that includes the *Depends header. Therefore we must always create the *Depends header. Ignore for now that *Depends headers are empty and pointless for module headers. Change-Id: I1dcc836788b3d46c4f1b504d2d64e9eb67b66206 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-05-20 14:17:06 +00:00
if (${hasModuleHeaders})
CMake: Add MODULE_INCLUDE_NAME one-value-keyword to qt_add_module This value is the equivalent of qt_module.prf's MODULE_INCNAME and can be used to specify a name for the module's include subdirectory. The default is Qt<ModuleName>. The include name is stored in the module's target property MODULE_INCLUDE_NAME. Change-Id: Ie6c8f6882ee2c3db78884ae5781593c803be3c05 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-05-15 09:37:08 +00:00
get_target_property(module_include_name "${target}" INTERFACE_MODULE_INCLUDE_NAME)
qt_internal_write_depends_file(${module_include_name} ${qtdeps})
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
endif()
if(third_party_deps OR main_module_tool_deps OR target_deps)
set(path_suffix "${INSTALL_CMAKE_NAMESPACE}${target}")
qt_path_join(config_build_dir ${QT_CONFIG_BUILD_DIR} ${path_suffix})
qt_path_join(config_install_dir ${QT_CONFIG_INSTALL_DIR} ${path_suffix})
# Configure and install ModuleDependencies file.
configure_file(
"${QT_CMAKE_DIR}/QtModuleDependencies.cmake.in"
"${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${target}Dependencies.cmake"
@ONLY
)
qt_install(FILES
"${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${target}Dependencies.cmake"
DESTINATION "${config_install_dir}"
COMPONENT Devel
)
Make module package depend on its own tool package Also make the tool package depend on all tool packages that correspond to the qt module dependencies. So find_package(Qt5Widgets) implicitly calls find_package(Qt5WidgetTools). And find_package(Qt5WidgetsTools) will call find_package for Qt5GuiTools, and Qt5CoreTools. This enhances the user experience, so that in modules like qtsvg, you don't have to specify both find_package(Qt5Widgets) and find_package(Qt5WidgetsTools), but only the former. Or when cross building, you only need to specify Qt5WidgetTools, to get both Core and Gui tools. Change-Id: Ib1c5173a5b97584a52e144c22e38e90a712f727a Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-04-29 12:36:25 +00:00
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
endif()
if(tool_deps)
Provide a way to specify extra tool package dependencies In the qtwayland repo, both WaylandClient and WaylandCompositor packages need access to the qtwaylandscanner tool. That means that the add_qt_tool(qtwaylandscanner) can't use the TOOLS_TARGET argument to associate a dependency with only one of the above modules. Instead add_qt_tool now allows specifying a non-existent module name for the TOOLS_TARGET argument, which can be manually depended on by other packages. Actually, you could specify the non-existent module before as well, but that didn't do everything that had to be done. This required a bit of refactoring in how the Dependencies file for Tools packages is created. Now the file is created in qt_export_tools. Two new functions were also added to allow recording additional dependencies between packages. Also some bug fixes were done to make it all work. Specifically the _FOUND variable generated in the Dependencies file was incorrect. Also there are some quotes missing when appending extra package dependencies via the QT_EXTRA_PACKAGE_DEPENDENCIES property. Change-Id: I167efec16dff8d036e191df3572ea72764e22bc5 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-11-15 15:28:17 +00:00
# The value of the property will be used by qt_export_tools.
set_property(TARGET "${target}" PROPERTY _qt_tools_package_deps "${tool_deps}")
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
endif()
endfunction()
function(qt_internal_create_plugin_depends_file target)
CMake: Prepare ground work for static Qml plugins importing For qt_import_qml_plugins to work, it needs to have access to the Qml plugin targets by the time find_package(Qt6Qml) is called. To do that, we modify the generation of Qml plugin Config, Targets and Dependencies files to go into a special 'QmlPlugins' subfolder of the Qml package. The Qml package will then GLOB include all the Config files in that folder, to make them available whenever find_package(Qt6Qml) is called. This is similar to how the Qt plugins were glob included in the CMake integration of Qt 5.15. In fact that glob including is missing in Qt 6 for regular Qt plugins, and should be implemented in a following change. Currently the Qt Plugins config files that are included are hardcoded to the list of known plugins at Qt configuration time. As a drive-by to make this all work, the naming of the various Config and Dependencies files has been normalized to include the Qt6 prefix. This is done for both regular Qt plugins and Qml plugins. Task-number: QTBUG-85961 Change-Id: Id20da72337ca2945fa330ea6fb43535e44a83292 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-10 14:44:13 +00:00
get_target_property(plugin_install_package_suffix "${target}" _qt_plugin_install_package_suffix)
Fix static builds There were a few issues: - Third party dependency info for plugins was not generated, because the depends and public_depends variables were not fetched. This caused issues when trying to use the qcocoa plugin in a consuming application, because Cups::Cups was not found. - Privately linked libraries in extend_target were not considered when generating dependency info for modules. This caused issues in QtThemeSupport, becauese it could not find Qt::DBus, due to that target only being added as a private library in a conditional scope. - Make sure to handle privately linked internal modules like PlatformModuleInternal to map to the Qt5 package, because there is no standalone package for it. Also remove a TODO comment that says that qt_register_target_dependencies should maybe be called in extend_target. That's already the case. Change-Id: Ie99c52e800cd89e6f82008f1e38f4da5cd602929 Reviewed-by: Qt CMake Build Bot Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-06-12 13:08:24 +00:00
get_target_property(depends "${target}" LINK_LIBRARIES)
get_target_property(public_depends "${target}" INTERFACE_LINK_LIBRARIES)
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
get_target_property(target_deps "${target}" _qt_target_deps)
set(target_deps_seen "")
QtPostProcess: Check target link-type when collecting deps Fixes a configure issue in qtgamepad Change-Id: I8212d6d58fd2f28ae71a9559cf6544102a873718 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
2019-09-24 13:53:41 +00:00
qt_collect_third_party_deps(${target})
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
# Dirty hack because https://gitlab.kitware.com/cmake/cmake/issues/19200
foreach(dep ${target_deps})
if(dep)
list(FIND target_deps_seen "${dep}" dep_seen)
if(dep_seen EQUAL -1)
list(LENGTH dep len)
if(NOT (len EQUAL 2))
message(FATAL_ERROR "List '${dep}' should look like QtFoo;version")
cmake: move dependencies accumulation in QtPostProcess.cmake This is needed because dependencies added after add_qt_module with extend_target are currently not taken into account. Task-number: QTBUG-75538 Change-Id: I2c72207fb88b2480e41a2c8550978fb194275617 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 09:38:41 +00:00
endif()
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
list(GET dep 0 dep_name)
list(GET dep 1 dep_ver)
cmake: move dependencies accumulation in QtPostProcess.cmake This is needed because dependencies added after add_qt_module with extend_target are currently not taken into account. Task-number: QTBUG-75538 Change-Id: I2c72207fb88b2480e41a2c8550978fb194275617 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 09:38:41 +00:00
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
list(APPEND target_deps_seen "${dep_name}\;${dep_ver}")
endif()
QtPostProcess: Fix generation of *Depends header files Normalize Qt module names before trying to match them. Deduplicate the names while at it. Change-Id: I5821c34fe5904cf9e9b986ac3ae4af2b248466b7 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2018-10-30 14:25:53 +00:00
endif()
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
endforeach()
set(target_deps "${target_deps_seen}")
QtPostProcess: Fix generation of *Depends header files Normalize Qt module names before trying to match them. Deduplicate the names while at it. Change-Id: I5821c34fe5904cf9e9b986ac3ae4af2b248466b7 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2018-10-30 14:25:53 +00:00
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
if(third_party_deps OR target_deps)
# Setup build and install paths
CMake: Prepare ground work for static Qml plugins importing For qt_import_qml_plugins to work, it needs to have access to the Qml plugin targets by the time find_package(Qt6Qml) is called. To do that, we modify the generation of Qml plugin Config, Targets and Dependencies files to go into a special 'QmlPlugins' subfolder of the Qml package. The Qml package will then GLOB include all the Config files in that folder, to make them available whenever find_package(Qt6Qml) is called. This is similar to how the Qt plugins were glob included in the CMake integration of Qt 5.15. In fact that glob including is missing in Qt 6 for regular Qt plugins, and should be implemented in a following change. Currently the Qt Plugins config files that are included are hardcoded to the list of known plugins at Qt configuration time. As a drive-by to make this all work, the naming of the various Config and Dependencies files has been normalized to include the Qt6 prefix. This is done for both regular Qt plugins and Qml plugins. Task-number: QTBUG-85961 Change-Id: Id20da72337ca2945fa330ea6fb43535e44a83292 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-10 14:44:13 +00:00
set(find_dependency_paths "\${CMAKE_CURRENT_LIST_DIR}/..")
if(plugin_install_package_suffix)
set(path_suffix "${INSTALL_CMAKE_NAMESPACE}${plugin_install_package_suffix}")
if(plugin_install_package_suffix MATCHES "/QmlPlugins")
# Qml plugins are one folder deeper.
set(find_dependency_paths "\${CMAKE_CURRENT_LIST_DIR}/../..")
endif()
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
else()
set(path_suffix "${INSTALL_CMAKE_NAMESPACE}${target}")
Begin port of qtbase to CMake Done-by: Alexandru Croitor <alexandru.croitor@qt.io> Done-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Done-by: Kevin Funk <kevin.funk@kdab.com> Done-by: Mikhail Svetkin <mikhail.svetkin@qt.io> Done-by: Simon Hausmann <simon.hausmann@qt.io> Done-by: Tobias Hunger <tobias.hunger@qt.io> Done-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Done-by: Volker Krause <volker.krause@kdab.com> Change-Id: Ida4f8bd190f9a4849a1af7b5b7981337a5df5310 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
2018-10-24 13:20:27 +00:00
endif()
Write find_dependency() calls in Qt Module config files This change introduces a new function called qt_find_package() which can take an extra option called PROVIDED_TARGETS, which associates targets with the package that defines those targets. This is done by setting the INTERFACE_QT_PACKAGE_NAME and INTERFACE_QT_PACKAGE_VERSION properties on the imported targets. This information allows us to generate appropriate find_dependency() calls in a module's Config file for third party libraries. For example when an application links against QtCore, it should also link against zlib and atomic libraries. In order to do that, the library locations first have to be found by CMake. This is achieved by embedding find_dependency(ZLIB) and find_dependency(Atomic) in Qt5CoreDependencies.cmake which is included by Qt5CoreConfig.cmake. The latter is picked up when an application project contains find_package(Qt5Core), and thus all linking dependencies are resolved. The information 'which package provides which targets' is contained in the python json2cmake conversion script. The generated output of the script contains qt_find_package() calls that represent that information. The Qt5CoreDependencies.cmake file and which which dependencies it contains is generated at the QtPostProcess stop. Note that for non-static Qt builds, we only need to propagate public 3rd party libraries. For static builds, we need all third party libraries. In order for the INTERFACE_QT_PACKAGE_NAME property to be read in any scope, the targets on which the property is set, have to be GLOBAL. Also for applications and other modules to find all required third party libraries, we have to install all our custom Find modules, and make sure they define INTERFACE IMPORTED libraries, and not just IMPORTED libraries. Change-Id: I694d6e32d05b96d5e241df0156fc79d0029426aa Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-04-24 15:14:25 +00:00
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
qt_path_join(config_build_dir ${QT_CONFIG_BUILD_DIR} ${path_suffix})
qt_path_join(config_install_dir ${QT_CONFIG_INSTALL_DIR} ${path_suffix})
Implement developer / non-prefix builds A non-prefix build is a build where you don't have to run make install. To do a non-prefix build, pass -DFEATURE_developer_build=ON when invoking CMake on qtbase. Note that this of course also enables developer build features (private tests, etc). When doing a non-prefix build, the CMAKE_INSTALL_PREFIX cache variable will point to the qtbase build directory. Tests can be run without installing Qt (QPA plugins are picked up from the build dir). This patch stops installation of any files by forcing the make "install" target be a no-op. When invoking cmake on the qtsvg module (or any other module), the CMAKE_INSTALL_PREFIX variable should be set to the qtbase build directory. The developer-build feature is propagated via the QtCore Config file, so that when building other modules, you don't have to specify it on the command line again. As a result of the change, all libraries, plugins, tools, include dirs, CMake Config files, CMake Targets files, Macro files, etc, will be placed in the qtbase build directory, mimicking the file layout of an installed Qt file layout. Only examples and tests are kept in the separate module build directories, which is equivalent to how qmake does it. The following global variables contain paths for the appropriate prefix or non prefix builds: QT_BUILD_DIR, QT_INSTALL_DIR, QT_CONFIG_BUILD_DIR, QT_CONFIG_INSTALL_DIR. These should be used by developers when deciding where files should be placed. All usages of install() are replaced by qt_install(), which has some additional logic on how to handle associationg of CMake targets to export names. When installing files, some consideration should be taken if qt_copy_or_install() needs to be used instead of qt_install(), which takes care of copying files from the source dir to the build dir when doing non-prefix builds. Tested with qtbase and qtsvg, developer builds, non-developer builds and static developer builds on Windows, Linux and macOS. Task-number: QTBUG-75581 Change-Id: I0ed27fb6467662dd24fb23aee6b95dd2c9c4061f Reviewed-by: Kevin Funk <kevin.funk@kdab.com> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-05-08 12:45:41 +00:00
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
# Configure and install ModuleDependencies file.
configure_file(
"${QT_CMAKE_DIR}/QtPluginDependencies.cmake.in"
CMake: Prepare ground work for static Qml plugins importing For qt_import_qml_plugins to work, it needs to have access to the Qml plugin targets by the time find_package(Qt6Qml) is called. To do that, we modify the generation of Qml plugin Config, Targets and Dependencies files to go into a special 'QmlPlugins' subfolder of the Qml package. The Qml package will then GLOB include all the Config files in that folder, to make them available whenever find_package(Qt6Qml) is called. This is similar to how the Qt plugins were glob included in the CMake integration of Qt 5.15. In fact that glob including is missing in Qt 6 for regular Qt plugins, and should be implemented in a following change. Currently the Qt Plugins config files that are included are hardcoded to the list of known plugins at Qt configuration time. As a drive-by to make this all work, the naming of the various Config and Dependencies files has been normalized to include the Qt6 prefix. This is done for both regular Qt plugins and Qml plugins. Task-number: QTBUG-85961 Change-Id: Id20da72337ca2945fa330ea6fb43535e44a83292 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-10 14:44:13 +00:00
"${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${target}Dependencies.cmake"
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
@ONLY
)
Implement developer / non-prefix builds A non-prefix build is a build where you don't have to run make install. To do a non-prefix build, pass -DFEATURE_developer_build=ON when invoking CMake on qtbase. Note that this of course also enables developer build features (private tests, etc). When doing a non-prefix build, the CMAKE_INSTALL_PREFIX cache variable will point to the qtbase build directory. Tests can be run without installing Qt (QPA plugins are picked up from the build dir). This patch stops installation of any files by forcing the make "install" target be a no-op. When invoking cmake on the qtsvg module (or any other module), the CMAKE_INSTALL_PREFIX variable should be set to the qtbase build directory. The developer-build feature is propagated via the QtCore Config file, so that when building other modules, you don't have to specify it on the command line again. As a result of the change, all libraries, plugins, tools, include dirs, CMake Config files, CMake Targets files, Macro files, etc, will be placed in the qtbase build directory, mimicking the file layout of an installed Qt file layout. Only examples and tests are kept in the separate module build directories, which is equivalent to how qmake does it. The following global variables contain paths for the appropriate prefix or non prefix builds: QT_BUILD_DIR, QT_INSTALL_DIR, QT_CONFIG_BUILD_DIR, QT_CONFIG_INSTALL_DIR. These should be used by developers when deciding where files should be placed. All usages of install() are replaced by qt_install(), which has some additional logic on how to handle associationg of CMake targets to export names. When installing files, some consideration should be taken if qt_copy_or_install() needs to be used instead of qt_install(), which takes care of copying files from the source dir to the build dir when doing non-prefix builds. Tested with qtbase and qtsvg, developer builds, non-developer builds and static developer builds on Windows, Linux and macOS. Task-number: QTBUG-75581 Change-Id: I0ed27fb6467662dd24fb23aee6b95dd2c9c4061f Reviewed-by: Kevin Funk <kevin.funk@kdab.com> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-05-08 12:45:41 +00:00
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
qt_install(FILES
CMake: Prepare ground work for static Qml plugins importing For qt_import_qml_plugins to work, it needs to have access to the Qml plugin targets by the time find_package(Qt6Qml) is called. To do that, we modify the generation of Qml plugin Config, Targets and Dependencies files to go into a special 'QmlPlugins' subfolder of the Qml package. The Qml package will then GLOB include all the Config files in that folder, to make them available whenever find_package(Qt6Qml) is called. This is similar to how the Qt plugins were glob included in the CMake integration of Qt 5.15. In fact that glob including is missing in Qt 6 for regular Qt plugins, and should be implemented in a following change. Currently the Qt Plugins config files that are included are hardcoded to the list of known plugins at Qt configuration time. As a drive-by to make this all work, the naming of the various Config and Dependencies files has been normalized to include the Qt6 prefix. This is done for both regular Qt plugins and Qml plugins. Task-number: QTBUG-85961 Change-Id: Id20da72337ca2945fa330ea6fb43535e44a83292 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-10 14:44:13 +00:00
"${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${target}Dependencies.cmake"
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
DESTINATION "${config_install_dir}"
COMPONENT Devel
)
endif()
endfunction()
CMake: Properly handle CONFIG += thread aka Threads::Threads mkspecs/features/qt.prf adds a dependency on the system threading library if the Qt Core thread feature is enabled. Because qt.prf is loaded by any public or internal Qt project, it's essentially a public dependency for any Qt consumer. To mimic that in CMake, we check if the thread feature is enabled, and and set the Threads::Threads library as a dependency of Qt6::Platform, which is a public target used by all Qt modules and plugins and Qt consumers. We also need to create a Qt6Dependencies.cmake file so we find_package(Threads) every time find_package(Qt6) is called. For the .prl files to be usable, we have to filter out some CMake implementation specific directory separator tokens 'CMAKE_DIRECTORY_ID_SEP' aka '::@', which are added because we call target_link_libraries() with a target created in a different scope (I think). As a result of this change, we shouldn't have to hardcode Threads::Threads in other projects, because it's now a global public dependency. Task-number: QTBUG-85801 Task-number: QTBUG-85877 Change-Id: Ib5d662c43b28e63f7da49d3bd77d0ad751220b31 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-03 14:28:16 +00:00
function(qt_internal_create_qt6_dependencies_file)
# This is used for substitution in the configured file.
set(target "${INSTALL_CMAKE_NAMESPACE}")
# This is the actual target we're querying.
set(actual_target Platform)
get_target_property(public_depends "${actual_target}" INTERFACE_LINK_LIBRARIES)
# We need to collect third party deps that are set on the public Platform target,
# like Threads::Threads.
# This mimics find_package part of the CONFIG += thread assignment in mkspecs/features/qt.prf.
qt_collect_third_party_deps(${actual_target})
# For Threads we also need to write an extra variable assignment.
set(third_party_extra "")
if(third_party_deps MATCHES "Threads")
string(APPEND third_party_extra "if(NOT QT_NO_THREADS_PREFER_PTHREAD_FLAG)
set(THREADS_PREFER_PTHREAD_FLAG TRUE)
endif()")
endif()
if(third_party_deps)
# Setup build and install paths.
set(path_suffix "${INSTALL_CMAKE_NAMESPACE}")
qt_path_join(config_build_dir ${QT_CONFIG_BUILD_DIR} ${path_suffix})
qt_path_join(config_install_dir ${QT_CONFIG_INSTALL_DIR} ${path_suffix})
# Configure and install QtDependencies file.
configure_file(
"${QT_CMAKE_DIR}/QtConfigDependencies.cmake.in"
"${config_build_dir}/${target}Dependencies.cmake"
@ONLY
)
qt_install(FILES
"${config_build_dir}/${target}Dependencies.cmake"
DESTINATION "${config_install_dir}"
COMPONENT Devel
)
endif()
endfunction()
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
# Create Depends.cmake & Depends.h files for all modules and plug-ins.
function(qt_internal_create_depends_files)
Abstract and fix usages of QT_KNOWN_MODULES In some places of the build system we need to iterate over repo specific Qt known modules (aka the ones that are built in the current project). In other places we need to iterate over the whole list of known Qt modules (those found via find_package + the ones built in the current project). Introduce two separate functions that provide access to either the former or latter, and adjust all existing usages of QT_KNOWN_MODULES as needed. Change-Id: Ica96d0cfe690b9aaaa3f8c53bc84975bccad69c7 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Qt CMake Build Bot Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
2019-08-20 13:24:14 +00:00
qt_internal_get_qt_repo_known_modules(repo_known_modules)
CMake: Properly handle CONFIG += thread aka Threads::Threads mkspecs/features/qt.prf adds a dependency on the system threading library if the Qt Core thread feature is enabled. Because qt.prf is loaded by any public or internal Qt project, it's essentially a public dependency for any Qt consumer. To mimic that in CMake, we check if the thread feature is enabled, and and set the Threads::Threads library as a dependency of Qt6::Platform, which is a public target used by all Qt modules and plugins and Qt consumers. We also need to create a Qt6Dependencies.cmake file so we find_package(Threads) every time find_package(Qt6) is called. For the .prl files to be usable, we have to filter out some CMake implementation specific directory separator tokens 'CMAKE_DIRECTORY_ID_SEP' aka '::@', which are added because we call target_link_libraries() with a target created in a different scope (I think). As a result of this change, we shouldn't have to hardcode Threads::Threads in other projects, because it's now a global public dependency. Task-number: QTBUG-85801 Task-number: QTBUG-85877 Change-Id: Ib5d662c43b28e63f7da49d3bd77d0ad751220b31 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-03 14:28:16 +00:00
if(PROJECT_NAME STREQUAL "QtBase")
qt_internal_create_qt6_dependencies_file()
endif()
Abstract and fix usages of QT_KNOWN_MODULES In some places of the build system we need to iterate over repo specific Qt known modules (aka the ones that are built in the current project). In other places we need to iterate over the whole list of known Qt modules (those found via find_package + the ones built in the current project). Introduce two separate functions that provide access to either the former or latter, and adjust all existing usages of QT_KNOWN_MODULES as needed. Change-Id: Ica96d0cfe690b9aaaa3f8c53bc84975bccad69c7 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Qt CMake Build Bot Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
2019-08-20 13:24:14 +00:00
foreach (target ${repo_known_modules})
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
qt_internal_create_module_depends_file(${target})
Begin port of qtbase to CMake Done-by: Alexandru Croitor <alexandru.croitor@qt.io> Done-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Done-by: Kevin Funk <kevin.funk@kdab.com> Done-by: Mikhail Svetkin <mikhail.svetkin@qt.io> Done-by: Simon Hausmann <simon.hausmann@qt.io> Done-by: Tobias Hunger <tobias.hunger@qt.io> Done-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Done-by: Volker Krause <volker.krause@kdab.com> Change-Id: Ida4f8bd190f9a4849a1af7b5b7981337a5df5310 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
2018-10-24 13:20:27 +00:00
endforeach()
Write find_dependency() calls in Qt Module config files This change introduces a new function called qt_find_package() which can take an extra option called PROVIDED_TARGETS, which associates targets with the package that defines those targets. This is done by setting the INTERFACE_QT_PACKAGE_NAME and INTERFACE_QT_PACKAGE_VERSION properties on the imported targets. This information allows us to generate appropriate find_dependency() calls in a module's Config file for third party libraries. For example when an application links against QtCore, it should also link against zlib and atomic libraries. In order to do that, the library locations first have to be found by CMake. This is achieved by embedding find_dependency(ZLIB) and find_dependency(Atomic) in Qt5CoreDependencies.cmake which is included by Qt5CoreConfig.cmake. The latter is picked up when an application project contains find_package(Qt5Core), and thus all linking dependencies are resolved. The information 'which package provides which targets' is contained in the python json2cmake conversion script. The generated output of the script contains qt_find_package() calls that represent that information. The Qt5CoreDependencies.cmake file and which which dependencies it contains is generated at the QtPostProcess stop. Note that for non-static Qt builds, we only need to propagate public 3rd party libraries. For static builds, we need all third party libraries. In order for the INTERFACE_QT_PACKAGE_NAME property to be read in any scope, the targets on which the property is set, have to be GLOBAL. Also for applications and other modules to find all required third party libraries, we have to install all our custom Find modules, and make sure they define INTERFACE IMPORTED libraries, and not just IMPORTED libraries. Change-Id: I694d6e32d05b96d5e241df0156fc79d0029426aa Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-04-24 15:14:25 +00:00
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
foreach (target ${QT_KNOWN_PLUGINS})
qt_internal_create_plugin_depends_file(${target})
endforeach()
endfunction()
Write find_dependency() calls in Qt Module config files This change introduces a new function called qt_find_package() which can take an extra option called PROVIDED_TARGETS, which associates targets with the package that defines those targets. This is done by setting the INTERFACE_QT_PACKAGE_NAME and INTERFACE_QT_PACKAGE_VERSION properties on the imported targets. This information allows us to generate appropriate find_dependency() calls in a module's Config file for third party libraries. For example when an application links against QtCore, it should also link against zlib and atomic libraries. In order to do that, the library locations first have to be found by CMake. This is achieved by embedding find_dependency(ZLIB) and find_dependency(Atomic) in Qt5CoreDependencies.cmake which is included by Qt5CoreConfig.cmake. The latter is picked up when an application project contains find_package(Qt5Core), and thus all linking dependencies are resolved. The information 'which package provides which targets' is contained in the python json2cmake conversion script. The generated output of the script contains qt_find_package() calls that represent that information. The Qt5CoreDependencies.cmake file and which which dependencies it contains is generated at the QtPostProcess stop. Note that for non-static Qt builds, we only need to propagate public 3rd party libraries. For static builds, we need all third party libraries. In order for the INTERFACE_QT_PACKAGE_NAME property to be read in any scope, the targets on which the property is set, have to be GLOBAL. Also for applications and other modules to find all required third party libraries, we have to install all our custom Find modules, and make sure they define INTERFACE IMPORTED libraries, and not just IMPORTED libraries. Change-Id: I694d6e32d05b96d5e241df0156fc79d0029426aa Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-04-24 15:14:25 +00:00
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
# This function creates the Qt<Module>Plugins.cmake used to list all
# the plug-in target files.
function(qt_internal_create_plugins_files)
Avoid unnecessary find_package calls when using Qt with shared builds Don't create the plugin config files when doing shared builds, otherwise for example Qt6GuiPlugins.cmake will try to include the xcb plugin cmake config, which in turn will perform a full-fledged find_package series to locate xcb. When an application just uses find_package(Qt6Gui), then that is not needed. Change-Id: I1890aaa5be8e214151c65fa981f547a73c0ca7fc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
2019-09-05 15:16:31 +00:00
# The plugins cmake configuration is only needed for static builds. Dynamic builds don't need
# the application to link against plugins at build time.
Fix unnecessary find_package calls for shared builds, part 2 Fix the silly boolean logic error in commit 9c1b7802d7f118b55ccc04dab74e1ee19e6d429f. Change-Id: I9dd0d3e8be5cbe75583099686a623d81d3dd87fc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-09-06 09:42:17 +00:00
if(QT_BUILD_SHARED_LIBS)
Avoid unnecessary find_package calls when using Qt with shared builds Don't create the plugin config files when doing shared builds, otherwise for example Qt6GuiPlugins.cmake will try to include the xcb plugin cmake config, which in turn will perform a full-fledged find_package series to locate xcb. When an application just uses find_package(Qt6Gui), then that is not needed. Change-Id: I1890aaa5be8e214151c65fa981f547a73c0ca7fc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
2019-09-05 15:16:31 +00:00
return()
endif()
Abstract and fix usages of QT_KNOWN_MODULES In some places of the build system we need to iterate over repo specific Qt known modules (aka the ones that are built in the current project). In other places we need to iterate over the whole list of known Qt modules (those found via find_package + the ones built in the current project). Introduce two separate functions that provide access to either the former or latter, and adjust all existing usages of QT_KNOWN_MODULES as needed. Change-Id: Ica96d0cfe690b9aaaa3f8c53bc84975bccad69c7 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Qt CMake Build Bot Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
2019-08-20 13:24:14 +00:00
qt_internal_get_qt_repo_known_modules(repo_known_modules)
message("Generating Plugins files for ${repo_known_modules}...")
foreach (QT_MODULE ${repo_known_modules})
Add support for Qt header_modules aka a header only INTERFACE library Also add support for modules that have no private module counterpart. Both are needed for Designer's QtUiPlugin in qttools. Change-Id: Ia7e9d8837140e1de5cd59e196b4f63481ab68298 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Qt CMake Build Bot
2019-08-19 13:07:22 +00:00
get_target_property(target_type "${QT_MODULE}" TYPE)
if(target_type STREQUAL "INTERFACE_LIBRARY")
# No plugins are provided by a header only module.
continue()
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
qt_path_join(config_build_dir ${QT_CONFIG_BUILD_DIR} ${INSTALL_CMAKE_NAMESPACE}${QT_MODULE})
qt_path_join(config_install_dir ${QT_CONFIG_INSTALL_DIR} ${INSTALL_CMAKE_NAMESPACE}${QT_MODULE})
set(QT_MODULE_PLUGIN_INCLUDES "")
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
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
get_target_property(qt_plugins "${QT_MODULE}" QT_PLUGINS)
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
if(qt_plugins)
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 (pluginTarget ${qt_plugins})
CMake: Prepare ground work for static Qml plugins importing For qt_import_qml_plugins to work, it needs to have access to the Qml plugin targets by the time find_package(Qt6Qml) is called. To do that, we modify the generation of Qml plugin Config, Targets and Dependencies files to go into a special 'QmlPlugins' subfolder of the Qml package. The Qml package will then GLOB include all the Config files in that folder, to make them available whenever find_package(Qt6Qml) is called. This is similar to how the Qt plugins were glob included in the CMake integration of Qt 5.15. In fact that glob including is missing in Qt 6 for regular Qt plugins, and should be implemented in a following change. Currently the Qt Plugins config files that are included are hardcoded to the list of known plugins at Qt configuration time. As a drive-by to make this all work, the naming of the various Config and Dependencies files has been normalized to include the Qt6 prefix. This is done for both regular Qt plugins and Qml plugins. Task-number: QTBUG-85961 Change-Id: Id20da72337ca2945fa330ea6fb43535e44a83292 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-10 14:44:13 +00:00
set(QT_MODULE_PLUGIN_INCLUDES "${QT_MODULE_PLUGIN_INCLUDES}include(\"\${CMAKE_CURRENT_LIST_DIR}/${INSTALL_CMAKE_NAMESPACE}${pluginTarget}Config.cmake\")\n")
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
endforeach()
CMake: Prepare ground work for static Qml plugins importing For qt_import_qml_plugins to work, it needs to have access to the Qml plugin targets by the time find_package(Qt6Qml) is called. To do that, we modify the generation of Qml plugin Config, Targets and Dependencies files to go into a special 'QmlPlugins' subfolder of the Qml package. The Qml package will then GLOB include all the Config files in that folder, to make them available whenever find_package(Qt6Qml) is called. This is similar to how the Qt plugins were glob included in the CMake integration of Qt 5.15. In fact that glob including is missing in Qt 6 for regular Qt plugins, and should be implemented in a following change. Currently the Qt Plugins config files that are included are hardcoded to the list of known plugins at Qt configuration time. As a drive-by to make this all work, the naming of the various Config and Dependencies files has been normalized to include the Qt6 prefix. This is done for both regular Qt plugins and Qml plugins. Task-number: QTBUG-85961 Change-Id: Id20da72337ca2945fa330ea6fb43535e44a83292 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-10 14:44:13 +00:00
endif()
if(QT_MODULE STREQUAL "Qml")
set(QT_MODULE_PLUGIN_INCLUDES "${QT_MODULE_PLUGIN_INCLUDES}
file(GLOB __qt_qml_plugins_config_file_list \"\${CMAKE_CURRENT_LIST_DIR}/QmlPlugins/${INSTALL_CMAKE_NAMESPACE}*Config.cmake\")
if (__qt_qml_plugins_config_file_list AND NOT QT_SKIP_AUTO_QML_PLUGIN_INCLUSION)
foreach(__qt_qml_plugin_config_file \${__qt_qml_plugins_config_file_list})
include(\${__qt_qml_plugin_config_file})
endforeach()
endif()")
endif()
if(QT_MODULE_PLUGIN_INCLUDES)
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
configure_file(
"${QT_CMAKE_DIR}/QtPlugins.cmake.in"
"${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${QT_MODULE}Plugins.cmake"
@ONLY
)
qt_install(FILES
"${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${QT_MODULE}Plugins.cmake"
DESTINATION "${config_install_dir}"
COMPONENT Devel
)
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
endif()
endforeach()
Begin port of qtbase to CMake Done-by: Alexandru Croitor <alexandru.croitor@qt.io> Done-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Done-by: Kevin Funk <kevin.funk@kdab.com> Done-by: Mikhail Svetkin <mikhail.svetkin@qt.io> Done-by: Simon Hausmann <simon.hausmann@qt.io> Done-by: Tobias Hunger <tobias.hunger@qt.io> Done-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Done-by: Volker Krause <volker.krause@kdab.com> Change-Id: Ida4f8bd190f9a4849a1af7b5b7981337a5df5310 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
2018-10-24 13:20:27 +00:00
endfunction()
CMake: Handle path components like INSTALL_LIBDIR more correctly We recomputed INSTALL_LIBDIR for every new repo that is configured, which is incorrect due losing any custom provided libdir when configuring qtbase. Save that information (and all other path components) in QtBuildInternalsConfigExtra.cmake. Make sure not to-recompute that information when configuring a project other than QtBase. Allow providing absolute paths instead of relative paths for these variables. Note that only absolute paths pointing somewhere under the prefix will currently work, otherwise configuraion will fail. If we need to support such a use case, we'll have to carefully check all code that use these path components to make sure they handle absolute paths correctly (current assumption is relative paths everywhere). Use the computed paths when generating the qconfig.cpp file which is used for qmake -query. Task-number: QTBUG-81289 Change-Id: I331aa00e47988fe0ee4e533b5f95c4df11c4d96f Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-03-06 16:06:45 +00:00
function(qt_generate_install_prefixes out_var)
set(content "\n")
set(vars INSTALL_BINDIR INSTALL_INCLUDEDIR INSTALL_LIBDIR INSTALL_MKSPECSDIR INSTALL_ARCHDATADIR
INSTALL_PLUGINSDIR INSTALL_LIBEXECDIR INSTALL_QMLDIR INSTALL_DATADIR INSTALL_DOCDIR
INSTALL_TRANSLATIONSDIR INSTALL_SYSCONFDIR INSTALL_EXAMPLESDIR INSTALL_TESTSDIR
INSTALL_DESCRIPTIONSDIR)
foreach(var ${vars})
get_property(docstring CACHE "${var}" PROPERTY HELPSTRING)
string(APPEND content "set(${var} \"${${var}}\" CACHE STRING \"${docstring}\" FORCE)\n")
endforeach()
set(${out_var} "${content}" PARENT_SCOPE)
endfunction()
CMake: Allow using single config generators after building with NMC Where NMC is the CMake Ninja Multi-Config generator. The first use case is to allow building standalone tests with one configuration even if Qt was build with multiple configurations. Another use case is for regular Qt consumers that might use the generated qt-cmake shell script which does not have the generator specified (as opposed to qt-cmake-private). Another detail is to use the first configuration from the initial Qt configurations list (CMAKE_CONFIGURATION_TYPES) when building standalone tests with a single config generator, so that it doesn't default to Debug, but rather to the provided first configuration. This matches qmake behavior, where on Windows with a debug_and_release configuration, tests are still built against release. Task-number: QTBUG-80900 Change-Id: I0da91c1f91095332cfe9e38d17f440aad6a09d15 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-05-13 16:31:26 +00:00
function(qt_wrap_string_in_if_multi_config content out_var)
set(${out_var} "
get_property(__qt_is_multi_config GLOBAL PROPERTY GENERATOR_IS_MULTI_CONFIG)
if(__qt_is_multi_config)
${content}endif()
unset(__qt_is_multi_config)\n" PARENT_SCOPE)
endfunction()
function(qt_wrap_string_in_if_ninja_multi_config content out_var)
set(${out_var} "if(CMAKE_GENERATOR STREQUAL \"Ninja Multi-Config\")
${content}endif()\n" PARENT_SCOPE)
endfunction()
CMake: Create Qt6HostInfo package This package is supposed to be loaded when cross-building Qt from the host Qt installation prefix. It provides information about the host Qt by setting various variables. The information reflects what "qmake -query" of the host Qt would return. All provided variable names begin with "QT6_HOST_INFO_". Change-Id: Id568923a318d6e3b48c450663519a3727f615a8f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-06-23 13:12:27 +00:00
function(qt_create_hostinfo_package)
set(package "${INSTALL_CMAKE_NAMESPACE}HostInfo")
qt_path_join(config_file_path "${QT_CONFIG_BUILD_DIR}/${package}/${package}Config.cmake")
qt_path_join(install_destination ${QT_CONFIG_INSTALL_DIR} ${package})
set(var_prefix "QT${PROJECT_VERSION_MAJOR}_HOST_INFO_")
configure_package_config_file(
"${CMAKE_CURRENT_LIST_DIR}/QtHostInfoConfig.cmake.in"
"${config_file_path}"
INSTALL_DESTINATION "${install_destination}"
NO_SET_AND_CHECK_MACRO
NO_CHECK_REQUIRED_COMPONENTS_MACRO)
qt_install(FILES "${config_file_path}" DESTINATION "${install_destination}")
endfunction()
Use the qt_build_repo() macros for building qtbase as well To implement this, create a new Qt5BuildInternals package. All child Qt modules like qtsvg should use find_package(Qt5BuildInternals) or find_package(Qt5 COMPONENTS BuildInternals) in the their top level CMakeLists.txt. This will make the qt_build_repo() macros available. For qtbase we slightly cheat, and specify a CMAKE_PREFIX_PATH pointing to the source folder that contains the BuildInternals package. For the other modules we actually use a configured and installed package Config file. This change moves variables that used to be written into the QtCore Config file into the BuildInternals package. This way things that are relevant only for building additional Qt modules does not pollute the QtCore package. Task-number: QTBUG-75580 Change-Id: I5479adff2f7903c9c2862d28c05c7f485ce3e4eb Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-05-15 11:57:15 +00:00
function(qt_generate_build_internals_extra_cmake_code)
if(PROJECT_NAME STREQUAL "QtBase")
CMake: Create Qt6HostInfo package This package is supposed to be loaded when cross-building Qt from the host Qt installation prefix. It provides information about the host Qt by setting various variables. The information reflects what "qmake -query" of the host Qt would return. All provided variable names begin with "QT6_HOST_INFO_". Change-Id: Id568923a318d6e3b48c450663519a3727f615a8f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-06-23 13:12:27 +00:00
qt_create_hostinfo_package()
Fix architecture config tests values to be written only once Every time the qtbase project was reconfigured, the list of config tests results was appended to a cache variable which was never reset, resulting in multiple copies of the same values being written to QtBuildInternalsExtra.cmake. Make sure to clean the cache variable before appending to it. Also change the variable to be all upper-case, to be consistent with other cache variables. Change-Id: Ic12046730a080595e19377981a726bc330641dc1 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-11-07 14:52:33 +00:00
foreach(var IN LISTS QT_BASE_CONFIGURE_TESTS_VARS_TO_EXPORT)
Export architecture config test variables Export the architecture configuration variables from QtBase. There are other modules that require access to this information in order to enable certain features (e.g: qml_jit in QtDeclarative). Change-Id: If2c7f29ccb1c0b0a0db3d78ad133a2a6be12b5ad Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-08-13 13:51:56 +00:00
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS "set(${var} \"${${var}}\" CACHE INTERNAL \"\")\n")
endforeach()
Ugly fix for handling QT_SOURCE_TREE QT_SOURCE_TREE is a variable that is set in qtbase/.qmake.conf. In qtbase, it's used throughout various projects to find cpp sources when building standalone tests (among other things). Everything works fine with qmake, because even if qmake is invoked on the tests subfolder, qmake searches up the source directory tree until it finds a .qmake.conf file, and uses that. When building qttools with qmake, the qdoc project expects to have a QT_SOURCE_TREE value, but it's not actually set in the qttools/.qmake.conf file, so the generated include paths that use that value are incorrect. Curiously the build still succeeds. Now in CMake land we replaced QT_SOURCE_TREE with CMAKE_SOURCE_DIR, but that does not work properly when doing a standalone tests build, because the project in that case is the tests one, and not the qtbase one, so configuration fails in a developer build when trying to configure some private tests. So far I've found that only qtbase actively uses this value. A temporary fix is to save the qtbase source directory into a QT_SOURCE_TREE variable inside the generated BuildInternalsExtra.cmake file. The pro2cmake script is changed to handle presence of QT_SOURCE_TREE in a qrc file path. This is handled by finding the location of a .qmake.conf file starting from the project file absolute path. This is needed to stop the script from crashing when handling the mimedatabase test projects for example. The change also regenerates the relevant failing test projects, and thus standalone tests (when doing developer builds aka private_tests enabled) now configure and build successfully. Change-Id: I15adc6f4ab6e3056c43ed850196204e2229c4d98 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-07-26 16:59:53 +00:00
set(QT_SOURCE_TREE "${QtBase_SOURCE_DIR}")
Use the qt_build_repo() macros for building qtbase as well To implement this, create a new Qt5BuildInternals package. All child Qt modules like qtsvg should use find_package(Qt5BuildInternals) or find_package(Qt5 COMPONENTS BuildInternals) in the their top level CMakeLists.txt. This will make the qt_build_repo() macros available. For qtbase we slightly cheat, and specify a CMAKE_PREFIX_PATH pointing to the source folder that contains the BuildInternals package. For the other modules we actually use a configured and installed package Config file. This change moves variables that used to be written into the QtCore Config file into the BuildInternals package. This way things that are relevant only for building additional Qt modules does not pollute the QtCore package. Task-number: QTBUG-75580 Change-Id: I5479adff2f7903c9c2862d28c05c7f485ce3e4eb Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-05-15 11:57:15 +00:00
qt_path_join(extra_file_path
${QT_CONFIG_BUILD_DIR}
${INSTALL_CMAKE_NAMESPACE}BuildInternals/QtBuildInternalsExtra.cmake)
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
if(CMAKE_BUILD_TYPE)
Fix CMAKE_BUILD_TYPE to be force set Otherwise CMake sets an up an empty default value itself, and then the value in QtBuildInternalsExtra does not end up being used, and then QtSetup ends up setting a Debug value. Amends 34a112e383d4ce3f6fe7417c1873fd3b33176032 Change-Id: If97a1d8c19ad5e7f690283997ff80dd9588cd521 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2020-01-30 13:21:34 +00:00
# Need to force set, because CMake itself initializes a value for CMAKE_BUILD_TYPE
# at the start of project configuration (with an empty value),
# so we need to force override it.
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(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
Fix CMAKE_BUILD_TYPE to be force set Otherwise CMake sets an up an empty default value itself, and then the value in QtBuildInternalsExtra does not end up being used, and then QtSetup ends up setting a Debug value. Amends 34a112e383d4ce3f6fe7417c1873fd3b33176032 Change-Id: If97a1d8c19ad5e7f690283997ff80dd9588cd521 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2020-01-30 13:21:34 +00:00
"set(CMAKE_BUILD_TYPE \"${CMAKE_BUILD_TYPE}\" CACHE STRING \"Choose the type of build.\" FORCE)\n")
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
endif()
if(CMAKE_CONFIGURATION_TYPES)
CMake: Allow using single config generators after building with NMC Where NMC is the CMake Ninja Multi-Config generator. The first use case is to allow building standalone tests with one configuration even if Qt was build with multiple configurations. Another use case is for regular Qt consumers that might use the generated qt-cmake shell script which does not have the generator specified (as opposed to qt-cmake-private). Another detail is to use the first configuration from the initial Qt configurations list (CMAKE_CONFIGURATION_TYPES) when building standalone tests with a single config generator, so that it doesn't default to Debug, but rather to the provided first configuration. This matches qmake behavior, where on Windows with a debug_and_release configuration, tests are still built against release. Task-number: QTBUG-80900 Change-Id: I0da91c1f91095332cfe9e38d17f440aad6a09d15 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-05-13 16:31:26 +00:00
string(APPEND multi_config_specific
" set(CMAKE_CONFIGURATION_TYPES \"${CMAKE_CONFIGURATION_TYPES}\" CACHE STRING \"\" FORCE)\n")
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
endif()
if(CMAKE_TRY_COMPILE_CONFIGURATION)
CMake: Allow using single config generators after building with NMC Where NMC is the CMake Ninja Multi-Config generator. The first use case is to allow building standalone tests with one configuration even if Qt was build with multiple configurations. Another use case is for regular Qt consumers that might use the generated qt-cmake shell script which does not have the generator specified (as opposed to qt-cmake-private). Another detail is to use the first configuration from the initial Qt configurations list (CMAKE_CONFIGURATION_TYPES) when building standalone tests with a single config generator, so that it doesn't default to Debug, but rather to the provided first configuration. This matches qmake behavior, where on Windows with a debug_and_release configuration, tests are still built against release. Task-number: QTBUG-80900 Change-Id: I0da91c1f91095332cfe9e38d17f440aad6a09d15 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-05-13 16:31:26 +00:00
string(APPEND multi_config_specific
" set(CMAKE_TRY_COMPILE_CONFIGURATION \"${CMAKE_TRY_COMPILE_CONFIGURATION}\")\n")
endif()
if(multi_config_specific)
qt_wrap_string_in_if_multi_config(
"${multi_config_specific}"
multi_config_specific)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS "${multi_config_specific}")
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
endif()
CMake: Allow using single config generators after building with NMC Where NMC is the CMake Ninja Multi-Config generator. The first use case is to allow building standalone tests with one configuration even if Qt was build with multiple configurations. Another use case is for regular Qt consumers that might use the generated qt-cmake shell script which does not have the generator specified (as opposed to qt-cmake-private). Another detail is to use the first configuration from the initial Qt configurations list (CMAKE_CONFIGURATION_TYPES) when building standalone tests with a single config generator, so that it doesn't default to Debug, but rather to the provided first configuration. This matches qmake behavior, where on Windows with a debug_and_release configuration, tests are still built against release. Task-number: QTBUG-80900 Change-Id: I0da91c1f91095332cfe9e38d17f440aad6a09d15 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-05-13 16:31:26 +00:00
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
if(QT_MULTI_CONFIG_FIRST_CONFIG)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
CMake: Allow using single config generators after building with NMC Where NMC is the CMake Ninja Multi-Config generator. The first use case is to allow building standalone tests with one configuration even if Qt was build with multiple configurations. Another use case is for regular Qt consumers that might use the generated qt-cmake shell script which does not have the generator specified (as opposed to qt-cmake-private). Another detail is to use the first configuration from the initial Qt configurations list (CMAKE_CONFIGURATION_TYPES) when building standalone tests with a single config generator, so that it doesn't default to Debug, but rather to the provided first configuration. This matches qmake behavior, where on Windows with a debug_and_release configuration, tests are still built against release. Task-number: QTBUG-80900 Change-Id: I0da91c1f91095332cfe9e38d17f440aad6a09d15 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-05-13 16:31:26 +00:00
"\nset(QT_MULTI_CONFIG_FIRST_CONFIG \"${QT_MULTI_CONFIG_FIRST_CONFIG}\")\n")
endif()
# When building standalone tests against a multi-config Qt, we want to choose the first
# configuration, rather than default to Debug.
if(multi_config_specific)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS "
if(QT_BUILD_STANDALONE_TESTS)
set(CMAKE_BUILD_TYPE \"\${QT_MULTI_CONFIG_FIRST_CONFIG}\" CACHE STRING \"Choose the type of build.\" FORCE)
endif()\n")
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
endif()
CMake: Allow using single config generators after building with NMC Where NMC is the CMake Ninja Multi-Config generator. The first use case is to allow building standalone tests with one configuration even if Qt was build with multiple configurations. Another use case is for regular Qt consumers that might use the generated qt-cmake shell script which does not have the generator specified (as opposed to qt-cmake-private). Another detail is to use the first configuration from the initial Qt configurations list (CMAKE_CONFIGURATION_TYPES) when building standalone tests with a single config generator, so that it doesn't default to Debug, but rather to the provided first configuration. This matches qmake behavior, where on Windows with a debug_and_release configuration, tests are still built against release. Task-number: QTBUG-80900 Change-Id: I0da91c1f91095332cfe9e38d17f440aad6a09d15 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-05-13 16:31:26 +00:00
CMake: Adapt to latest upstream Ninja Multi-Config changes Most of the NMC-specific variables were renamed to be more general. Change-Id: I8ee2874fecb9e57480ce51db9183c6cf3dd100af Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-03-02 13:16:38 +00:00
if(CMAKE_CROSS_CONFIGS)
CMake: Allow using single config generators after building with NMC Where NMC is the CMake Ninja Multi-Config generator. The first use case is to allow building standalone tests with one configuration even if Qt was build with multiple configurations. Another use case is for regular Qt consumers that might use the generated qt-cmake shell script which does not have the generator specified (as opposed to qt-cmake-private). Another detail is to use the first configuration from the initial Qt configurations list (CMAKE_CONFIGURATION_TYPES) when building standalone tests with a single config generator, so that it doesn't default to Debug, but rather to the provided first configuration. This matches qmake behavior, where on Windows with a debug_and_release configuration, tests are still built against release. Task-number: QTBUG-80900 Change-Id: I0da91c1f91095332cfe9e38d17f440aad6a09d15 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-05-13 16:31:26 +00:00
string(APPEND ninja_multi_config_specific
" set(CMAKE_CROSS_CONFIGS \"${CMAKE_CROSS_CONFIGS}\" CACHE STRING \"\")\n")
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
endif()
CMake: Adapt to latest upstream Ninja Multi-Config changes Most of the NMC-specific variables were renamed to be more general. Change-Id: I8ee2874fecb9e57480ce51db9183c6cf3dd100af Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-03-02 13:16:38 +00:00
if(CMAKE_DEFAULT_BUILD_TYPE)
CMake: Allow using single config generators after building with NMC Where NMC is the CMake Ninja Multi-Config generator. The first use case is to allow building standalone tests with one configuration even if Qt was build with multiple configurations. Another use case is for regular Qt consumers that might use the generated qt-cmake shell script which does not have the generator specified (as opposed to qt-cmake-private). Another detail is to use the first configuration from the initial Qt configurations list (CMAKE_CONFIGURATION_TYPES) when building standalone tests with a single config generator, so that it doesn't default to Debug, but rather to the provided first configuration. This matches qmake behavior, where on Windows with a debug_and_release configuration, tests are still built against release. Task-number: QTBUG-80900 Change-Id: I0da91c1f91095332cfe9e38d17f440aad6a09d15 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-05-13 16:31:26 +00:00
string(APPEND ninja_multi_config_specific
" set(CMAKE_DEFAULT_BUILD_TYPE \"${CMAKE_DEFAULT_BUILD_TYPE}\" CACHE STRING \"\")\n")
endif()
CMake: Default to building all configurations with Ninja Multi-Config Thus we will build both Release and Debug configurations in Coin when cmake --build . is executed, mimicking qmake's make which builds both configurations in debug_and_release. Task-number: QTBUG-80900 Change-Id: If48aca249eb84e690d3f9d51a733b3a25df1f7ca Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-05-14 15:02:59 +00:00
if(CMAKE_DEFAULT_CONFIGS)
string(APPEND ninja_multi_config_specific
" set(CMAKE_DEFAULT_CONFIGS \"${CMAKE_DEFAULT_CONFIGS}\" CACHE STRING \"\")\n")
endif()
CMake: Allow using single config generators after building with NMC Where NMC is the CMake Ninja Multi-Config generator. The first use case is to allow building standalone tests with one configuration even if Qt was build with multiple configurations. Another use case is for regular Qt consumers that might use the generated qt-cmake shell script which does not have the generator specified (as opposed to qt-cmake-private). Another detail is to use the first configuration from the initial Qt configurations list (CMAKE_CONFIGURATION_TYPES) when building standalone tests with a single config generator, so that it doesn't default to Debug, but rather to the provided first configuration. This matches qmake behavior, where on Windows with a debug_and_release configuration, tests are still built against release. Task-number: QTBUG-80900 Change-Id: I0da91c1f91095332cfe9e38d17f440aad6a09d15 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-05-13 16:31:26 +00:00
if(ninja_multi_config_specific)
qt_wrap_string_in_if_ninja_multi_config(
"${ninja_multi_config_specific}"
ninja_multi_config_specific)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS "${ninja_multi_config_specific}")
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
endif()
CMake: Allow using single config generators after building with NMC Where NMC is the CMake Ninja Multi-Config generator. The first use case is to allow building standalone tests with one configuration even if Qt was build with multiple configurations. Another use case is for regular Qt consumers that might use the generated qt-cmake shell script which does not have the generator specified (as opposed to qt-cmake-private). Another detail is to use the first configuration from the initial Qt configurations list (CMAKE_CONFIGURATION_TYPES) when building standalone tests with a single config generator, so that it doesn't default to Debug, but rather to the provided first configuration. This matches qmake behavior, where on Windows with a debug_and_release configuration, tests are still built against release. Task-number: QTBUG-80900 Change-Id: I0da91c1f91095332cfe9e38d17f440aad6a09d15 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-05-13 16:31:26 +00:00
CMake: Fix auto-detection of precompiled header support PCH files were only used while building qtbase. Make sure the value is exported to the BuildInternalsConfig file, so the value is re-used when building other repositories. Also disable PCH when building simulator_and_device iOS builds, because CMake doesn't currently generate separate PCH files per architecture. Change-Id: I79955ebc557b800bc3c704deac519fe80012c229 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2020-03-24 10:19:21 +00:00
if(DEFINED BUILD_WITH_PCH)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
"set(BUILD_WITH_PCH \"${BUILD_WITH_PCH}\" CACHE STRING \"\")\n")
endif()
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
CMake: Make it possible to build tools when cross-compiling This patch allows tools to be built for the target platform when the QT_BUILD_TOOLS_WHEN_CROSSCOMPILING parameter is set at configuration time. To avoid naming conflicts, the target tools are suffixed with "_native". The qt_get_tool_target_name() function can be used to get the tool name for both scenarios (cross and non-cross compilation). Extend pro2cmake to refer to the right target name for tools. The relevant write_XXX functions have a new target_ref parameter that will be "${target_name}" for tools and literally the target name for everything else. Fixes: QTBUG-81901 Change-Id: If4efbc1fae07a4a3a044dd09c9c06be6d517825e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-27 13:04:57 +00:00
if(CMAKE_CROSSCOMPILING AND QT_BUILD_TOOLS_WHEN_CROSSCOMPILING)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
"set(QT_BUILD_TOOLS_WHEN_CROSSCOMPILING \"TRUE\" CACHE BOOL \"\" FORCE)\n")
endif()
CMake: Improve sanitizer detection The change fixes the labels to show up correctly in the configure summary. It also allows enabling the sanitizer via the feature flags, e.g. -DFEATURE_sanitize_address=ON. Finally the qtbase sanitizer option is saved in QtBuildInternalsExtra so that repos built after qtbase have the same sanitizer options enabled. Change-Id: Ic9d9e3ce3c7ebbc244ced2e6d163d1ac8ee06b12 Fixes: QTBUG-84721 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-06-15 07:50:42 +00:00
if(ECM_ENABLE_SANITIZERS)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
"set(ECM_ENABLE_SANITIZERS \"${ECM_ENABLE_SANITIZERS}\" CACHE BOOL \"\" FORCE)\n")
endif()
CMake: Handle automatic rpath embedding correctly Instead of using CMAKE_INSTALL_RPATH to embed an absolute path to prefix/libdir into all targets, use the more sophisticated aproach that qmake does. For certain targets (modules, plugins, tools) use relative rpaths. Otherwise embed absolute paths (examples, regular binaries). Installed tests currently have no rpaths. On certain platforms rpaths are not used (Windows, Android, iOS / uikit). Frameworks, app bundles and shallow bundles should also be handled correctly. Additional rpaths can be provided via QT_EXTRA_RPATHS variable (similar to the -R option that configure takes). Automatic embedding can be disabled either via QT_FEATURE_rpath=OFF or QT_DISABLE_RPATH=ON. Note that installed examples are not relocatable at the moment (due to always having an absolute path rpath), so this is a missing feature compared to qmake. This is due to missing information on where examples will be installed, so a relative rpath can not be computed. By default a Qt installation is relocatable, so there is no need to pass -DQT_EXTRA_RPATHS=. like Coin used to do with qmake e.g. -R . Relative rpaths will have the appropriate 'relative base' prefixed to them (e.g $ORIGIN on linux and @loader_path on darwin platforms). There is currently no support for other platforms that might have a different 'relative base' than the ones mentioned above. Any extra rpaths are saved to BuildInternalsExtra which are re-used when building other repositories. configurejson2cmake modified to include correct conditions for the rpath feature. It's very likely that we will need a new qt_add_internal_app() function for gui apps that are to be installed to prefix/bin. For example for Assistant from qttools. Currently such apps use qt_add_executable(). The distinction is necessary to make sure that relative rpaths are embedded into apps, but not executables (which tests are part of). Amends e835a6853b9c0fb7af32798ed8965de3adf0e15b Task-number: QTBUG-83497 Change-Id: I3510f63c0a59489741116cc8ec3ef6a0a7704f25 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-04-15 16:48:26 +00:00
# Rpath related things that need to be re-used when building other repos.
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
"set(CMAKE_INSTALL_RPATH \"${CMAKE_INSTALL_RPATH}\" CACHE STRING \"\")\n")
if(DEFINED QT_DISABLE_RPATH)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
"set(QT_DISABLE_RPATH \"${QT_DISABLE_RPATH}\" CACHE STRING \"\")\n")
endif()
if(DEFINED QT_EXTRA_RPATHS)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
"set(QT_EXTRA_RPATHS \"${QT_EXTRA_RPATHS}\" CACHE STRING \"\")\n")
endif()
CMake: Don't use libraries in /usr/local by default on macOS qmake builds of Qt don't use libraries in /usr/local because the path is not considered a system path. Only the SDK path should be used as a source of system libraries. We should do the same for the CMake builds, which involves a couple of things. Tell CMake not to consider /usr/local (and a bunch of other paths) as system prefix paths. Disable pkg-config usage which by default is not used in qmake Windows and macOS builds. If a user wishes to use libraries located in /usr/local on macOS, they can explicitly enable the behavior via -DFEATURE_pkg_config=ON. In addition to enabling pkg-config, that will also disable the system prefix modification described above. Implementation notes To disable pkg-config usage, we set an empty path for PKG_CONFIG_EXECUTABLE, because there is no other good way. The downside to this is that a lot of warning messages will be printed that the pkg-config package can not be found. The pkg-config feature needs to be computed in QtBuildInternals before qtbase/src/configure.cmake, because it's too late to do it in that file where a few qt_find_package calls already exist. The feature value is also saved to QtBuildInternalsExtra, to make sure that pkg-config is disabled whenever building another repo. System prefix adjustment is done by removing paths from CMAKE_SYSTEM_PREFIX_PATH. Ideally we would remove also /usr as a path, to match what qmake does, but that breaks find_program() calls for perl, python, etc. We have to make sure that qt_find_package does not look in PATH when looking for packages, which is the default behavior, because PATH on macOS most likely contains /usr/local. One last curiosity for future generations is that CMake 3.18+ has merged a change to prioritise SDK locations over regular /usr/lib. Fixes: QTBUG-85261 Change-Id: I28fe5bae7997507a83b37b4eb1e0188e64062c57 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2020-06-25 16:02:52 +00:00
# Save pkg-config feature value to be able to query it internally as soon as BuildInternals
# package is loaded. This is to avoid any pkg-config package from being found when
# find_package(Qt6Core) is called in case if the feature was disabled.
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS "
if(NOT QT_SKIP_BUILD_INTERNALS_PKG_CONFIG_FEATURE)
set(FEATURE_pkg_config \"${FEATURE_pkg_config}\" CACHE STRING \"Using pkg-config\" FORCE)
endif()\n")
CMake: Save OPENSSL_ROOT_DIR in QtBuildInternalsExtra This is needed so that other repos other than qtbase (like qtopcua) can still find_package(WrapOpenSSL) successfully. The path needs to be converted to a CMake path, to avoid issues on Windows with backslashes. Change-Id: I3d7652d93110f6b8f39a58a6c28aef6c7471aea7 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-06-04 15:10:51 +00:00
# The OpenSSL root dir needs to be saved so that repos other than qtbase (like qtopcua) can
# still successfully find_package(WrapOpenSSL) in the CI.
# qmake saves any additional include paths passed via the configure like '-I/foo'
# in mkspecs/qmodule.pri, so this file is the closest equivalent.
if(DEFINED OPENSSL_ROOT_DIR)
file(TO_CMAKE_PATH "${OPENSSL_ROOT_DIR}" openssl_root_cmake_path)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
"set(OPENSSL_ROOT_DIR \"${openssl_root_cmake_path}\" CACHE STRING \"\")\n")
endif()
CMake: Fix QT_STAGING_PREFIX for repos other than qtbase For repositories other than qtbase the QT_STAGING_PREFIX was empty, because it was only determined in qtbase. Also, we save the CMAKE_STAGING_PREFIX in the Qt6BuildInternals package and set this variable if it's not explicitly set by the user. As with CMAKE_INSTALL_PREFIX this behavior can be prevented by defining QT_BUILD_INTERNALS_NO_FORCE_SET_STAGING_PREFIX=ON. Change-Id: I73100abbef24f5d3fb8f82029d0374176edc8048 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-07-13 07:22:46 +00:00
if(NOT "${CMAKE_STAGING_PREFIX}" STREQUAL "")
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
"
# If no explicit CMAKE_STAGING_PREFIX is provided, force set the original Qt staging prefix,
if(\"$\{CMAKE_STAGING_PREFIX}\" STREQUAL \"\"
AND NOT QT_BUILD_INTERNALS_NO_FORCE_SET_STAGING_PREFIX)
set(CMAKE_STAGING_PREFIX \"${CMAKE_STAGING_PREFIX}\" CACHE PATH
\"Staging path prefix, prepended onto install directories on the host machine.\" FORCE)
endif()
")
endif()
CMake: Handle path components like INSTALL_LIBDIR more correctly We recomputed INSTALL_LIBDIR for every new repo that is configured, which is incorrect due losing any custom provided libdir when configuring qtbase. Save that information (and all other path components) in QtBuildInternalsConfigExtra.cmake. Make sure not to-recompute that information when configuring a project other than QtBase. Allow providing absolute paths instead of relative paths for these variables. Note that only absolute paths pointing somewhere under the prefix will currently work, otherwise configuraion will fail. If we need to support such a use case, we'll have to carefully check all code that use these path components to make sure they handle absolute paths correctly (current assumption is relative paths everywhere). Use the computed paths when generating the qconfig.cpp file which is used for qmake -query. Task-number: QTBUG-81289 Change-Id: I331aa00e47988fe0ee4e533b5f95c4df11c4d96f Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-03-06 16:06:45 +00:00
qt_generate_install_prefixes(install_prefix_content)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS "${install_prefix_content}")
CMake: Make build system of installed Qt more relocatable Aka handle CMAKE_INSTALL_PREFIX in a more relocatable way. The following story inspired this change. If a user wants to build a Qt repo into a different install prefix than the usual Qt one, this will fail configuration because we look for various things like syncqt, qdoc, etc relative to CMAKE_INSTALL_PREFIX, which will now point to a different location where none of the above tools are located. The intent for such a use case is to support building Qt packages with Conan, which sets a random install prefix when configuring a repo. The idea is to derive the qt prefix dynamically from the QtBuildInternals package location. Essentially it's a reverse relative path from the QtBuildInternalsConfig.cmake file to the install prefix that was specified when initially configuring qtbase. Once the dynamic prefix is computed (so we know where the possibly relocated Qt is), we can find tools like syncqt and qdoc. This is an initial attempt to support a use case like that. More design work will probably needed in case if tools / libs need to be found in a location different than the Qt install prefix (so support for multiple install prefixes / search paths). An example of such a case would be when building qtdeclarative and qtquickcontrols2 as Conan packages in one go. Most likely the qmltyperegistrar tool will be located in the random install prefix set by Conan, so building qtquickcontrols2 might fail due to not finding the tool in the original Qt install prefix. As to the implementation details, the change does the following: - Dynamically computes and sets the QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX variable when find_package()'ing QtBuildInternals. It's an absolute path pointing to where the relocated Qt is. - When building qtbase this variable is not yet available (due to QtBuildInternalsExtra not existing), in that case we set the variable to the absolute path of CMAKE_INSTALL_PREFIX (but only for the initial qtbase configuration). - Remove QT_BUILD_INTERNALS_ORIGINAL_INSTALL_PREFIX which was used for standalone tests purposes. It's not needed now that we compute the location of the Qt prefix dynamically. - The Unixy qt-cmake and qt-cmake-private shell scripts now use a relative path to find the toolchain file we created. - The toolchain file also dynamically computes the location of the Qt packages, and adds them to CMAKE_PREFIX_PATH. - A lot of existing CMAKE_INSTALL_PREFIX uses are replaced with QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX. This includes finding tool locations, mkspecs dir, path environment setup for tools, etc. - Some places still use CMAKE_PREFIX_PATH in the following cases - When determining paths while configuring qtbase (valid cases) - When I wasn't sure what the behavior should be, so I left them as-is (an example is documentation generation, do we want to install it into the random Conan prefix, or into the main prefix? Currently it installs in the random prefix). Note that relocating a Qt installation does not work for non-prefix / non-installed builds, due to hardcoded paths to include directories and libraries in generated FooTargets.cmake files. Task-number: QTBUG-83999 Change-Id: I87d6558729db93121b1715771034b03ce3295923 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-05-05 08:30:35 +00:00
qt_compute_relative_path_from_cmake_config_dir_to_prefix()
cmake: Generate QtBuildInternalsExtra at conftime ... using configure_file. Change-Id: Ibe3522c33e20a86c454b23919547775624f84755 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-06-05 15:15:20 +00:00
configure_file(
"${CMAKE_CURRENT_LIST_DIR}/QtBuildInternalsExtra.cmake.in"
"${extra_file_path}"
@ONLY
)
Use the qt_build_repo() macros for building qtbase as well To implement this, create a new Qt5BuildInternals package. All child Qt modules like qtsvg should use find_package(Qt5BuildInternals) or find_package(Qt5 COMPONENTS BuildInternals) in the their top level CMakeLists.txt. This will make the qt_build_repo() macros available. For qtbase we slightly cheat, and specify a CMAKE_PREFIX_PATH pointing to the source folder that contains the BuildInternals package. For the other modules we actually use a configured and installed package Config file. This change moves variables that used to be written into the QtCore Config file into the BuildInternals package. This way things that are relevant only for building additional Qt modules does not pollute the QtCore package. Task-number: QTBUG-75580 Change-Id: I5479adff2f7903c9c2862d28c05c7f485ce3e4eb Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-05-15 11:57:15 +00:00
endif()
endfunction()
Android: Final changes for APK generation Generate the ${MODULE}-android-dependencies.xml for the androiddeployqt tool. This will ensure all the right plugins and dependencies are packaged when generating the apk. This change also changes the visibility for executable to default/public. Not having this will cause the application to crash as we can't locate main() in the executable (shared library). Additionally pro2cmake conversion script has been updated to perform the required conversions for the Android settings. Finally, the 6 projects in QtBase that have Android dependencies have been updated with the new script and the step that produces the xml files in run at the end in QtPostProcess.cmake. Change-Id: I9774ba1b123bc11cae972fa37054ef2c51988498 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-06-24 12:54:40 +00:00
# For every Qt module check if there any android dependencies that require
# processing.
function(qt_modules_process_android_dependencies)
Abstract and fix usages of QT_KNOWN_MODULES In some places of the build system we need to iterate over repo specific Qt known modules (aka the ones that are built in the current project). In other places we need to iterate over the whole list of known Qt modules (those found via find_package + the ones built in the current project). Introduce two separate functions that provide access to either the former or latter, and adjust all existing usages of QT_KNOWN_MODULES as needed. Change-Id: Ica96d0cfe690b9aaaa3f8c53bc84975bccad69c7 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Qt CMake Build Bot Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
2019-08-20 13:24:14 +00:00
qt_internal_get_qt_repo_known_modules(repo_known_modules)
foreach (target ${repo_known_modules})
Android: Final changes for APK generation Generate the ${MODULE}-android-dependencies.xml for the androiddeployqt tool. This will ensure all the right plugins and dependencies are packaged when generating the apk. This change also changes the visibility for executable to default/public. Not having this will cause the application to crash as we can't locate main() in the executable (shared library). Additionally pro2cmake conversion script has been updated to perform the required conversions for the Android settings. Finally, the 6 projects in QtBase that have Android dependencies have been updated with the new script and the step that produces the xml files in run at the end in QtPostProcess.cmake. Change-Id: I9774ba1b123bc11cae972fa37054ef2c51988498 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-06-24 12:54:40 +00:00
qt_android_dependencies(${target})
endforeach()
endfunction()
Create module tools packages (config files) automatically Previously you had to make sure to use DISABLE_TOOLS_EXPORT in an add_qt_module call if the tools are built after the module, as well as to manually call qt_export_tools after all associated tools are built. This was needlessly complex, especially for people that are porting a repo with tools for the first time. The tools package creation is now automatically done at QtPostProcess step, so there is no need to use either DISABLE_TOOLS_EXPORT or qt_export_tools() manually. DISABLE_TOOLS_EXPORT is now a no-op, and will be removed once all repos are updated not to use it. Change-Id: I965b0d3a8a0cb908afae87b047083ed7bea9f02f Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-09-21 19:22:09 +00:00
function(qt_create_tools_config_files)
# Create packages like Qt6CoreTools/Qt6CoreToolsConfig.cmake.
foreach(module_name ${QT_KNOWN_MODULES_WITH_TOOLS})
qt_export_tools("${module_name}")
endforeach()
endfunction()
Make standalone tests build via top level repo project Previously repo/tests/CMakeLists.txt was a standalone project on which CMake could be called. This was useful for Coin to be able to build and package only tests, but was a bit troublesome because that means having to specify the usual boilerplate like minimum CMake version, which packages to find in every tests.pro project. Instead of having a separate standalone project, modify the top level project and associated CMake code to allow passing a special QT_BUILD_STANDALONE_TESTS variable, which causes the top level project to build only tests, and find Qt in the previously installed qt location. This also means that when building a repo, we generate a ${repo_name}TestsConfig.cmake file which does find_package on all the modules that have been built as part of that repo. So that when standalone tests bare built for that repo, the modules are automatically found. qt_set_up_standalone_tests_build() is modified to be a no-op because it is not needed anymore. Its usage should be removed from all the other repos, and then removed from qtbase. Non-adjusted tests/CMakeLists.txt projects in other repositories should still be buildable with the current code, until they are updated to the new format. Adjust the Coin build instructions to build the standalone tests in a separate directory. Adjust pro2cmake to generate new structure for the tests/tests.pro projects. Adjust the qtbase tests project. Fixes: QTBUG-79239 Change-Id: Ib4b66bc772d8876cdcbae1e90ce5a5a5234fa675 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-11-01 10:48:23 +00:00
function(qt_internal_create_config_file_for_standalone_tests)
set(standalone_tests_config_dir "StandaloneTests")
qt_path_join(config_build_dir
${QT_CONFIG_BUILD_DIR}
"${INSTALL_CMAKE_NAMESPACE}BuildInternals" "${standalone_tests_config_dir}")
qt_path_join(config_install_dir
${QT_CONFIG_INSTALL_DIR}
"${INSTALL_CMAKE_NAMESPACE}BuildInternals" "${standalone_tests_config_dir}")
CMake: Allow building bundled 3rd party libraries in qtbase A few things are needed to accomplish that: - the python scripts do not ignore certain system_foo features anymore (it is a hardcoded list for now just to be safe) - configurejson2cmake now outputs qt_find_package(WrapSystemFoo) calls for bundled libraries (see below) - the harfbuzz .pro file is modified to accommodate pro2cmake not being able to correctly parse some conditional scopes - the freetype .pro file is modified to make sure linking of the library succeeds without duplicate symbol errors, which qmake doesn't encounter due to magical exclusion of cpp files that are included in other cpp files (presumably for include moc_foo.cpp support) - feature evaluation for Core, Gui, Network now happens in the qtbase/src directory, so that bundled libraries can be conditionally built - for each bundled library there are now two FindWrap scripts: - FindWrapSystemFoo which finds an installed library in the system - FindWrapFoo which either uses the system installed library or the built bundled one depending on a condition - projects that intend to use bundled libraries need to link against WrapFoo::WrapFoo instead of WrapSystemFoo::WrapSystemFoo targets (this is handled by pro2cmake). Unfortunately manually added qt_find_package(WrapFoo) calls might still be needed as is the case for WrapFreetype and others. - a new cmake/QtFindWrapHelper.cmake file is added that provides a macro to simplify creation of WrapFoo targets that link against a bundled or system library. The implementation is fairly ugly due to CMake macro constraints, but it was deemed better than copy-pasting a bunch of almost identical code across all FindWrapFoo.cmake files. - a qtzlib header-only module is now created when using bundled zlib, to provide public syncqt created headers for consumers that need them. These are projects that have 'QT_PRIVATE += zlib-private' in their .pro files (e.g. qtimageformats, qtlocation, qt3d, etc.) This is unfortunately needed due to QtNetwork using zlib types in its private C++ API. The change includes support for building the following bundled libraries: - zlib - libpng - libjpeg - Freetype - Harfbuzz-ng - PCRE2 The following 3rd party libraries are still using an old implementation within the CMake build system, and should be migrated to the new one in the near future: - double-conversion - Old harfbuzz The are a few libraries that are not yet ported: - system-sqlite - systemxcb - maybe others Among other things, this change allows building qtbase on Windows without requiring vcpkg. Task-number: QTBUG-82167 Change-Id: I35ecea0d832f66c1943c82e618de4a51440971a5 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
2020-02-14 13:53:28 +00:00
# Filter out bundled system libraries. Otherwise when looking for their dependencies
# (like PNG for Freetype) FindWrapPNG is searched for during configuration of
# standalone tests, and it can happen that Core or Gui features are not
# imported early enough, which means FindWrapPNG will try to find a system PNG library instead
# of the bundled one.
set(modules)
foreach(m ${QT_REPO_KNOWN_MODULES})
get_target_property(target_type "${m}" TYPE)
# Interface libraries are never bundled system libraries (hopefully).
if(target_type STREQUAL "INTERFACE_LIBRARY")
list(APPEND modules "${m}")
continue()
endif()
get_target_property(is_3rd_party "${m}" QT_MODULE_IS_3RDPARTY_LIBRARY)
if(NOT is_3rd_party)
list(APPEND modules "${m}")
endif()
endforeach()
list(JOIN modules " " QT_REPO_KNOWN_MODULES_STRING)
Make standalone tests build via top level repo project Previously repo/tests/CMakeLists.txt was a standalone project on which CMake could be called. This was useful for Coin to be able to build and package only tests, but was a bit troublesome because that means having to specify the usual boilerplate like minimum CMake version, which packages to find in every tests.pro project. Instead of having a separate standalone project, modify the top level project and associated CMake code to allow passing a special QT_BUILD_STANDALONE_TESTS variable, which causes the top level project to build only tests, and find Qt in the previously installed qt location. This also means that when building a repo, we generate a ${repo_name}TestsConfig.cmake file which does find_package on all the modules that have been built as part of that repo. So that when standalone tests bare built for that repo, the modules are automatically found. qt_set_up_standalone_tests_build() is modified to be a no-op because it is not needed anymore. Its usage should be removed from all the other repos, and then removed from qtbase. Non-adjusted tests/CMakeLists.txt projects in other repositories should still be buildable with the current code, until they are updated to the new format. Adjust the Coin build instructions to build the standalone tests in a separate directory. Adjust pro2cmake to generate new structure for the tests/tests.pro projects. Adjust the qtbase tests project. Fixes: QTBUG-79239 Change-Id: Ib4b66bc772d8876cdcbae1e90ce5a5a5234fa675 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-11-01 10:48:23 +00:00
string(STRIP "${QT_REPO_KNOWN_MODULES_STRING}" QT_REPO_KNOWN_MODULES_STRING)
Don't install QtFooTestsConfig.cmake if no modules were built When configuring qtx11extras on macOS, we ended up installing the file, which made Coin think that at least one module was built, and thus it tried to build tests as well. Don't install the file if no modules were built, thus preventing from trying to build tests in Coin. Amends de3a806def4b9a754825a2233c9d4952a9b2d0eb Change-Id: I920a0b40a6ded12140f251352da53b68eef6560d Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-11-12 11:57:17 +00:00
# Skip generating and installing file if no modules were built. This make sure not to install
# anything when build qtx11extras on macOS for example.
if(NOT QT_REPO_KNOWN_MODULES_STRING)
return()
endif()
Make standalone tests build via top level repo project Previously repo/tests/CMakeLists.txt was a standalone project on which CMake could be called. This was useful for Coin to be able to build and package only tests, but was a bit troublesome because that means having to specify the usual boilerplate like minimum CMake version, which packages to find in every tests.pro project. Instead of having a separate standalone project, modify the top level project and associated CMake code to allow passing a special QT_BUILD_STANDALONE_TESTS variable, which causes the top level project to build only tests, and find Qt in the previously installed qt location. This also means that when building a repo, we generate a ${repo_name}TestsConfig.cmake file which does find_package on all the modules that have been built as part of that repo. So that when standalone tests bare built for that repo, the modules are automatically found. qt_set_up_standalone_tests_build() is modified to be a no-op because it is not needed anymore. Its usage should be removed from all the other repos, and then removed from qtbase. Non-adjusted tests/CMakeLists.txt projects in other repositories should still be buildable with the current code, until they are updated to the new format. Adjust the Coin build instructions to build the standalone tests in a separate directory. Adjust pro2cmake to generate new structure for the tests/tests.pro projects. Adjust the qtbase tests project. Fixes: QTBUG-79239 Change-Id: Ib4b66bc772d8876cdcbae1e90ce5a5a5234fa675 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-11-01 10:48:23 +00:00
# Ceate a Config file that calls find_package on the modules that were built as part
# of the current repo. This is used for standalone tests.
configure_file(
"${QT_CMAKE_DIR}/QtStandaloneTestsConfig.cmake.in"
Implement qtbase fixes for superbuilds Change-Id: I0d3445cf0740e3925fa9342dac4d07892518afe5 Reviewed-by: Qt CMake Build Bot Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2019-11-21 12:33:28 +00:00
"${config_build_dir}/${PROJECT_NAME}TestsConfig.cmake"
Make standalone tests build via top level repo project Previously repo/tests/CMakeLists.txt was a standalone project on which CMake could be called. This was useful for Coin to be able to build and package only tests, but was a bit troublesome because that means having to specify the usual boilerplate like minimum CMake version, which packages to find in every tests.pro project. Instead of having a separate standalone project, modify the top level project and associated CMake code to allow passing a special QT_BUILD_STANDALONE_TESTS variable, which causes the top level project to build only tests, and find Qt in the previously installed qt location. This also means that when building a repo, we generate a ${repo_name}TestsConfig.cmake file which does find_package on all the modules that have been built as part of that repo. So that when standalone tests bare built for that repo, the modules are automatically found. qt_set_up_standalone_tests_build() is modified to be a no-op because it is not needed anymore. Its usage should be removed from all the other repos, and then removed from qtbase. Non-adjusted tests/CMakeLists.txt projects in other repositories should still be buildable with the current code, until they are updated to the new format. Adjust the Coin build instructions to build the standalone tests in a separate directory. Adjust pro2cmake to generate new structure for the tests/tests.pro projects. Adjust the qtbase tests project. Fixes: QTBUG-79239 Change-Id: Ib4b66bc772d8876cdcbae1e90ce5a5a5234fa675 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-11-01 10:48:23 +00:00
@ONLY
)
qt_install(FILES
Implement qtbase fixes for superbuilds Change-Id: I0d3445cf0740e3925fa9342dac4d07892518afe5 Reviewed-by: Qt CMake Build Bot Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2019-11-21 12:33:28 +00:00
"${config_build_dir}/${PROJECT_NAME}TestsConfig.cmake"
Make standalone tests build via top level repo project Previously repo/tests/CMakeLists.txt was a standalone project on which CMake could be called. This was useful for Coin to be able to build and package only tests, but was a bit troublesome because that means having to specify the usual boilerplate like minimum CMake version, which packages to find in every tests.pro project. Instead of having a separate standalone project, modify the top level project and associated CMake code to allow passing a special QT_BUILD_STANDALONE_TESTS variable, which causes the top level project to build only tests, and find Qt in the previously installed qt location. This also means that when building a repo, we generate a ${repo_name}TestsConfig.cmake file which does find_package on all the modules that have been built as part of that repo. So that when standalone tests bare built for that repo, the modules are automatically found. qt_set_up_standalone_tests_build() is modified to be a no-op because it is not needed anymore. Its usage should be removed from all the other repos, and then removed from qtbase. Non-adjusted tests/CMakeLists.txt projects in other repositories should still be buildable with the current code, until they are updated to the new format. Adjust the Coin build instructions to build the standalone tests in a separate directory. Adjust pro2cmake to generate new structure for the tests/tests.pro projects. Adjust the qtbase tests project. Fixes: QTBUG-79239 Change-Id: Ib4b66bc772d8876cdcbae1e90ce5a5a5234fa675 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-11-01 10:48:23 +00:00
DESTINATION "${config_install_dir}"
COMPONENT Devel
)
endfunction()
Begin port of qtbase to CMake Done-by: Alexandru Croitor <alexandru.croitor@qt.io> Done-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Done-by: Kevin Funk <kevin.funk@kdab.com> Done-by: Mikhail Svetkin <mikhail.svetkin@qt.io> Done-by: Simon Hausmann <simon.hausmann@qt.io> Done-by: Tobias Hunger <tobias.hunger@qt.io> Done-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Done-by: Volker Krause <volker.krause@kdab.com> Change-Id: Ida4f8bd190f9a4849a1af7b5b7981337a5df5310 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
2018-10-24 13:20:27 +00:00
qt_internal_create_depends_files()
Use the qt_build_repo() macros for building qtbase as well To implement this, create a new Qt5BuildInternals package. All child Qt modules like qtsvg should use find_package(Qt5BuildInternals) or find_package(Qt5 COMPONENTS BuildInternals) in the their top level CMakeLists.txt. This will make the qt_build_repo() macros available. For qtbase we slightly cheat, and specify a CMAKE_PREFIX_PATH pointing to the source folder that contains the BuildInternals package. For the other modules we actually use a configured and installed package Config file. This change moves variables that used to be written into the QtCore Config file into the BuildInternals package. This way things that are relevant only for building additional Qt modules does not pollute the QtCore package. Task-number: QTBUG-75580 Change-Id: I5479adff2f7903c9c2862d28c05c7f485ce3e4eb Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-05-15 11:57:15 +00:00
qt_generate_build_internals_extra_cmake_code()
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 14:03:15 +00:00
qt_internal_create_plugins_files()
Make standalone tests build via top level repo project Previously repo/tests/CMakeLists.txt was a standalone project on which CMake could be called. This was useful for Coin to be able to build and package only tests, but was a bit troublesome because that means having to specify the usual boilerplate like minimum CMake version, which packages to find in every tests.pro project. Instead of having a separate standalone project, modify the top level project and associated CMake code to allow passing a special QT_BUILD_STANDALONE_TESTS variable, which causes the top level project to build only tests, and find Qt in the previously installed qt location. This also means that when building a repo, we generate a ${repo_name}TestsConfig.cmake file which does find_package on all the modules that have been built as part of that repo. So that when standalone tests bare built for that repo, the modules are automatically found. qt_set_up_standalone_tests_build() is modified to be a no-op because it is not needed anymore. Its usage should be removed from all the other repos, and then removed from qtbase. Non-adjusted tests/CMakeLists.txt projects in other repositories should still be buildable with the current code, until they are updated to the new format. Adjust the Coin build instructions to build the standalone tests in a separate directory. Adjust pro2cmake to generate new structure for the tests/tests.pro projects. Adjust the qtbase tests project. Fixes: QTBUG-79239 Change-Id: Ib4b66bc772d8876cdcbae1e90ce5a5a5234fa675 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-11-01 10:48:23 +00:00
qt_internal_create_config_file_for_standalone_tests()
Android: Final changes for APK generation Generate the ${MODULE}-android-dependencies.xml for the androiddeployqt tool. This will ensure all the right plugins and dependencies are packaged when generating the apk. This change also changes the visibility for executable to default/public. Not having this will cause the application to crash as we can't locate main() in the executable (shared library). Additionally pro2cmake conversion script has been updated to perform the required conversions for the Android settings. Finally, the 6 projects in QtBase that have Android dependencies have been updated with the new script and the step that produces the xml files in run at the end in QtPostProcess.cmake. Change-Id: I9774ba1b123bc11cae972fa37054ef2c51988498 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-06-24 12:54:40 +00:00
Provide a way to specify extra tool package dependencies In the qtwayland repo, both WaylandClient and WaylandCompositor packages need access to the qtwaylandscanner tool. That means that the add_qt_tool(qtwaylandscanner) can't use the TOOLS_TARGET argument to associate a dependency with only one of the above modules. Instead add_qt_tool now allows specifying a non-existent module name for the TOOLS_TARGET argument, which can be manually depended on by other packages. Actually, you could specify the non-existent module before as well, but that didn't do everything that had to be done. This required a bit of refactoring in how the Dependencies file for Tools packages is created. Now the file is created in qt_export_tools. Two new functions were also added to allow recording additional dependencies between packages. Also some bug fixes were done to make it all work. Specifically the _FOUND variable generated in the Dependencies file was incorrect. Also there are some quotes missing when appending extra package dependencies via the QT_EXTRA_PACKAGE_DEPENDENCIES property. Change-Id: I167efec16dff8d036e191df3572ea72764e22bc5 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-11-15 15:28:17 +00:00
# Needs to run after qt_internal_create_depends_files.
qt_create_tools_config_files()
Android: Final changes for APK generation Generate the ${MODULE}-android-dependencies.xml for the androiddeployqt tool. This will ensure all the right plugins and dependencies are packaged when generating the apk. This change also changes the visibility for executable to default/public. Not having this will cause the application to crash as we can't locate main() in the executable (shared library). Additionally pro2cmake conversion script has been updated to perform the required conversions for the Android settings. Finally, the 6 projects in QtBase that have Android dependencies have been updated with the new script and the step that produces the xml files in run at the end in QtPostProcess.cmake. Change-Id: I9774ba1b123bc11cae972fa37054ef2c51988498 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-06-24 12:54:40 +00:00
if (ANDROID)
qt_modules_process_android_dependencies()
endif()
CMake: Generate qmake .prl files This commit also adds a qt_finalize_module function that is called for every Qt module after all link dependencies have been added. Change-Id: I489d188d05e368208a8a62828bb12fb395df54bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-12 15:16:55 +00:00
# Install prl files
CMake: Generate .prl files for plugins in static Qt builds To successfully link plugins of a static Qt build into a Qt project we need to generate .prl files for the plugins. Task-number: QTBUG-84781 Change-Id: I1406052f2269050aa7cbe6aa2b546bece1c68467 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-06-12 19:34:52 +00:00
get_property(prl_install_dirs GLOBAL PROPERTY QT_PRL_INSTALL_DIRS)
foreach(prl_install_dir ${prl_install_dirs})
qt_install(DIRECTORY "${PROJECT_BINARY_DIR}/${prl_install_dir}/"
DESTINATION ${prl_install_dir}
FILES_MATCHING PATTERN "*.prl"
)
endforeach()
Reference in New Issue Copy Permalink