summaryrefslogtreecommitdiffstats
path: root/cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Add public FindPackageHelpersDominik Holland2021-06-145-4/+6
| | | | | | | | | This makes qt_internal_disable_find_package_global_promotion available, which is needed when linking against QtMultimedia in a static build Pick-to: 6.2 Change-Id: I9b8f6d7b74a8693ac471f8a280e893f4da80a44b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Allow tools to enable exceptionsRobert Griebl2021-06-141-1/+7
| | | | | | | | | | Needed for the QtApplicationManager tools. Pick-to: 6.2 Change-Id: I987b297406b6659d777ce5c00f9fc1b89ccc80ab Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Replace flags with spaces when removing themAlexey Edelev2021-06-121-2/+2
| | | | | | | | | | | Removing flags based on REGEX may include spaces, so flags might be glued. Replace flags with spaces to keep at least one space for the described case. Pick-to: 6.2 6.1 Fixes: QTBUG-94400 Change-Id: Ice268da36174ef5cf4398d2aee8fcd4731336316 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Fix internal module mappings of the qtdeclarative repoAlexey Edelev2021-06-111-2/+2
| | | | | | | | Add 'Private' suffix to the internal module names in the mappings of the qmake files for modules of the qtdeclarative repo. Change-Id: I1592ebad0f0db553322ea766561b1b8c3fd38aea Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add the check for linker capabilities to resolve circular dependenciesAlexey Edelev2021-06-108-2/+202
| | | | | | | | | | | | | | 'ld' only capable to resolve circular dependencies by wrapping the suspected static libraries and objects using --start/end-group arguments. We want to detect if linker is 'ld' at configure time to decide how to link the resource objects if finalizers are not enabled. The qt_config_compile_test function is extended with an extra argument since it's required to pass custom cmake flags to the ld-related test. Pick-to: 6.2 Change-Id: I484fcc99e2886952d8b0232f37e4e6a35d072931 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix global 'apk' target to apply to Qt EXTERNAL_BUILD examplesAlexandru Croitor2021-06-081-0/+17
| | | | | | | | | | | This means calling 'ninja apk' in a Qt build with examples configured will build all example apks, regardless of whether the examples are built as external projects or in-tree. Fixes: QTBUG-94264 Change-Id: I5c7af0354858898a2e154a6d54fb025e4d81ff80 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* wasm: fix threaded buildsLorn Potter2021-06-081-2/+4
| | | | | | | set the thread pool size default to 4 Change-Id: I038a81610c82ac4d162c044d0e1f58196cffc7b7 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* CMake: Add support for building with clang-clCristian Adam2021-06-042-2/+4
| | | | | | | | | qmake had support for building with clang-cl as the win32-clang-msvc mkspec. Task-number: QTBUG-89642 Task-number: QTBUG-88081 Change-Id: I0709c289f90fedb121620d1e67ef841602219816 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Remove CMake compatibility functions for old APIJoerg Bornemann2021-06-043-114/+0
| | | | | | | | | All repositories define QT_NO_INTERNAL_COMPATIBILITY_FUNCTIONS by now, and we can remove QtCompatibilityHelpers.cmake altogether. Change-Id: I4d8104246e96a4514d5651c104607d651d208d95 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix support for using system supplied md4c libraryNiclas Rosenvik2021-06-031-0/+24
| | | | | | | | | | | | | | | | | | | Add FindWrapSystemMd4c.cmake so that the old md4c target can be used as well as the new one and set WrapSystemMd4c_FOUND. Link to the imported target WrapSystemMd4c::WrapSystemMd4c if the system library is used. Add qt_find_package line to find the package in configure.cmake. Fix the condition for enabling system-textmarkdownreader, it includes testing for textmarkdownreader because even if the code would compile correctly without it, it looks strange when the output says "textmarkdownreader no" and under "using system libmd4c yes" even if libmd4c is not used. Use system include when system-markdownreader is enabled. Add library mapping for libmd4c. Change-Id: Id5d5b13d6691a8c1cdf627238887977c847c1e67 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Move resource object files to the beginning of linker line in .prl filesAlexey Edelev2021-06-031-1/+1
| | | | | | | | | Move collected resource objects to the beginning of the linker line to prevent order-related issues. Fixes: QTBUG-92250 Change-Id: Ia046f2820feb693bfadc2b60e07fa001638d4d7b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix location of qtattributionsscanner in doc buildsKai Köhne2021-06-031-6/+9
| | | | | | | | qtattributionsscanner is now found in libexec. Task-number: QTBUG-88791 Change-Id: Ie704663012be92b0c223d9d57210ec1874abff0b Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Make framework names consistent with the module namesAlexey Edelev2021-06-034-18/+25
| | | | | | | | | | | | | | | | | | For Apple's frameworks it's possible to include header files using the following assumption: If the framework name is "MyFramework" then '#include <MyFramework/frameworkheader.h>' will work without specifying the include path explicitly. This is broken for internal modules since they use the framework name with the 'Private' suffix. This uses the module name instead of the target name as a framework name. Amends edbe0eb335ca4c0fde23f57eae5acdf80937c9e3 Task-number: QTBUG-87775 Change-Id: I0592a28d0768724b6e10ca81aa7cefb0a3699a5e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Collect resource objects of plugins and their dependencies in finalizerAlexey Edelev2021-06-031-2/+32
| | | | | | | | | | | | | Resource objects might be linked to plugins. Since some plugins may be present in LINK_LIBRARIES as the complex genexes, need to collect them explicitly and iterate over plugin targets to find resource object libraries that need to be exposed to end-point target executable. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Change-Id: Icd85f54f7bf9d1b7e3382caa5d9aa62449b6adb8 Reviewed-by: Lorn Potter <lorn.potter@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Explicitly generate static plugin helpers into binary dirUlf Hermann2021-06-031-2/+2
| | | | | | | Before, it would erroneously look for them in the source directory. Change-Id: I6dcd3ccde3e57dba84639da2cd354c51e8a92459 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix generated prl and pri files for MSVCLi Xinwei2021-06-025-5/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In MSVC static build, if we build Qt with 3rdparty library (e.g. zstd), cmake will add"zstd" (without "-l" prefix) to Qt6Core.prl. Then we use this Qt to build a qmake project, compilation will fail due to missing zstd.obj. Without "-l" prefix, qmake will treat "zstd" as an object file instead of a library. Library names in qt_module.pri and qt_lib_*_private.pri are also missing "-l" prefix. This is because on most compilers, CMAKE_LINK_LIBRARY_FLAG equals "-l". But on MSVC, it is an empty string. So we should pass "-DLINK_LIBRARY_FLAG=-l" for MSVC. Also add "-L/path/to/library" if the library path is not in default linker search directories. This will write un-relocatable paths to prl files only when using 3rdparty libraries to build Qt statically. Usually it's not a problem. In addition, CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES is also empty on MSVC. So The third argument of "$<FILTER>" is empty, it is an invalid generator expression. This means no include dir will be written to qt_module.pri and qt_lib_*_private.pri on MSVC. So only use "$<FILTER>" when CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES is not empty. Pick-to: 6.1 Change-Id: Ib66f95dc09cf920363a4b9338fb97747dd2f8ab7 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix EXTRA_CMAKE_FILES behavior of qt_internal_add_toolJoerg Bornemann2021-06-011-9/+24
| | | | | | | | | | | | | ...and make it consistent with that of qt_internal_add_module. Make EXTRA_CMAKE_FILES a multi value keyword. Do not add include statements for every file in EXTRA_CMAKE_FILES. Add the EXTRA_CMAKE_INCLUDES argument to specify includes. This enables us to specify EXTRA_CMAKE_FILE that are not included. Change-Id: I1a3667473b94ee44363b554ab9e6c380e5c11389 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Pass OpenGL_GL_PREFERENCE variable to other Qt reposJoerg Bornemann2021-06-011-0/+8
| | | | | | | | | | | | | | When building Linux packages, we pass OpenGL_GL_PREFERENCE=LEGACY when building qtbase. This is done to link against legacy OpenGL libs. When building non-qtbase repos, we also need to set this variable to the same value we have in qtbase. Pick-to: 6.1 Task-number: QTBUG-89754 Fixes: QTBUG-94040 Change-Id: I567b629d245025d2b1544b91cfc265a9c921725f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Do not get LINK_LIBRARY of the interface librariesAlexey Edelev2021-06-011-1/+7
| | | | | | | | | | Avoid getting the LINK_LIBRARY property of the interface libraries when calling a resource object finalizer. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Change-Id: I19d625a927c66994902f5c89e6c82183c94af91e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Create global imported versionless tool targetsAlexandru Croitor2021-06-011-1/+1
| | | | | | | | | | | | | | Versioned tool targets are always promoted to global targets. Versionless ones were not promoted to global targets. This was an oversight which caused issues with conditions like if(TARGET Qt::Tool) in top-level builds. Fixes: QTBUG-93839 Change-Id: I5176899b5d0d80bfd0b350bc9c4b3fa5b53c0777 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Allow printing config summary even if module is not builtAlexandru Croitor2021-06-012-1/+23
| | | | | | | | | | | | | | In the future it might be useful to print the config summary entries of a Qt module configure.cmake file even if the associated module is not built and thus qt_feature_module_begin is not called. The repo src/CMakeLists.txt could then use a combination of qt_feature_evaluate_features and a conditional qt_feature_record_summary_entries to ensure the that summary entries are still shown. Change-Id: I124efc82163ddae48d9e72c70a677ec4c6588fac Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Move the framework related information to the common functionAlexey Edelev2021-05-314-26/+62
| | | | | | | | | | Since the information about framework is performed in multiple places it's quite hard to control its consistency. This moves the obtaining of framework related information to the common function and adjusts the use of the information across the repo. Change-Id: I1f488d41dcea75a1e8c361926792a6b7c45e5a3f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Rework resource finalizer approachAlexey Edelev2021-05-311-10/+40
| | | | | | | | | | | | | | | | In the previous implementation of the resource object finalizer, we used the name of the resource object library without namespaces when recording it in the resource libraries list. This causes an issue when we or users export resource targets. This approach marks resource object libraries with the exporting property instead of collecting resource targets when creating them. Amends 19e789bace887105badae83c0a79429bbf8e8221 Change-Id: I8596815921f2c681ddd78d9b2e9a4e1cafe5000b Reviewed-by: Lorn Potter <lorn.potter@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Implement propagation of object files to the end-point executableAlexey Edelev2021-05-274-0/+56
| | | | | | | | | | | | | | | | | | | | This proposal collects all the resource objects to the qt-specific property of the static libraries. This is done to avoid littering of other static libraries and put resource object files to the source part of the linker line when linking the end-point executable. The way we link object resource libraries is changed back to the target_link_libraries approach as we may omit using finalizers with linkers other than ld. Users may enforce finalizers by calling the qt6_enable_resource_objects_finalizer_mode function if need. Refactor tests related to the static resources. Amends ddaa7150d85624ab545ccfe098fe8b2d18241940 Task-number: QTBUG-93002 Change-Id: I74135e291cd82fb54d1b284b4b4a1e002b1fef98 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Revise plugin finalizer mode usageAlexandru Croitor2021-05-271-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Only use plugin finalizer mode if qt_finalize_target is called at the end of the user project (which we can't really check, the user has to ensure that) or when qt_finalize_target is automatically defer-called by CMake 3.19+ (which is done by qt_add_executable). This removes the previous behavior of using the finalizer mode if qt_import_plugins is called. Instead the old regular mode is used if the above preconditions are not met. The removed behavior had ordering issues if qt_import_plugins was called before target_link_libraries. The dependency walking would be done before Qt dependencies were added and thus no plugins would be linked. Amends 6fcc272ac9dcf1d6d65de1bdf3138722ba63a902 Task-number: QTBUG-80863 Task-number: QTBUG-92933 Task-number: QTBUG-94030 Change-Id: I78702b653a35596f5581c2f4282b2336f0124e60 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* wasm: fix cmake syntax for emscriptenLorn Potter2021-05-271-4/+4
| | | | | | | | | | | fix debugging demangler Emscripten apparently does not like the quotes in the compiler argument and remove array syntax Change-Id: I66652f6bdc5872faf540a877ca01bf75dde47bbb Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Use the correct framework name when preparing the framework pathsAlexey Edelev2021-05-271-1/+1
| | | | | | | | Amends 425ff34aa10a02524f2d52f544dc00b539ef9a26 Task-number: QTBUG-87775 Change-Id: Ic79e77255e1f3aec9748a6770838f9eeeae94d38 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Build examples in isolated sub-builds using ExternalProjectCraig Scott2021-05-261-9/+220
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Examples are intended to show how to build against an installed Qt. Building them as part of the main build means the way the Qt targets are defined and created are not representative of an end user's build. By building them as separate projects using ExternalProject, we can more closely replicate the intended audience's environment. This should allow us to catch more problems earlier. Having examples built as part of the main build also creates problems with some static builds where a tool built by the main build is needed during configure time. This happens with other repos like qtdeclarative but not (currently) with qtbase. Converting the examples in qtbase to be built using ExternalProject is intended as a demonstrator for how other repos can do similar. Until other repos are converted, they will continue to work as they did before, with examples as part of the main build for non-static builds only. The new build-externally behavior is only supported for non-prefix builds with this change. Prefix builds will continue to use the old non-external method. Support for building examples externally in prefix builds will be a separate change. Task-number: QTBUG-90820 Fixes: QTBUG-91068 Change-Id: I2304329940568dbdb7da18d54d5595ea7d8668bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Remove some dead installation codeAlexandru Croitor2021-05-251-17/+0
| | | | | | | | It was copy-pasted (presumably from plugin handling code) when initially introduced but was never used. Change-Id: I571738b9f5269ca038f5931a773aa5c2c66aafbc Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Introduce a public qt_add_library functionAlexandru Croitor2021-05-252-88/+132
| | | | | | | | | | | | | | | | | | | | | | Internally it uses a new _qt_internal_add_library function (similar how we have qt_add_executable and _qt_internal_add_executable) as well as finalizer code line the executable case. _qt_internal_add_library forwards arguments to add_library with some Qt specific adjustments to the selected default target type (based on whether Qt is configured as static or shared). The new _qt_internal_add_library is now used in qt_add_plugin as well as some internal library creating functions like qt_internal_add_module. This reduces some duplication of file name adjustments across functions and creates a central point for creation of Qt-like libraries (for some definition of Qt-like). Change-Id: Id9a31fe6bf278c8c3bb1e61e00a9febf7f1a2664 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* CMake: fix CMake function qt_commandline_addStringHaoyu Liu2021-05-251-1/+1
| | | | | | | | | 1. a missing '}' breaks CMake 2. the variable "opt" should really be "arg", otherwise it'll be meaningless Pick-to: 6.1 Change-Id: If29557998bf7aa786dc5c821e2c55f1195e7922b Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Add _qt_module_interface_name for 3rdparty librariesAlexey Edelev2021-05-231-0/+3
| | | | | | | | | | | Since we add 3rdparty libraries to the set of the Qt modules, they are treated as the Qt modules by the depenedcy helper as well. So give them _qt_module_interface_name to fix dependency helper. Amends 425ff34aa10a02524f2d52f544dc00b539ef9a26 Change-Id: I5898c1c90156de1878aeeef5a0924349b44c50fa Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Add export of the Private targets for the internal modulesAlexey Edelev2021-05-221-8/+6
| | | | | | | | | | | We need to export the Private targets of the internal modules to keep compatibility with existing internal module users across repositories. Amends 425ff34aa10a02524f2d52f544dc00b539ef9a26 Fixes: QTBUG-93943 Change-Id: I10234cec1eb618b69d041f80fbe29620a4e307b9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* qmake: Pick default architecture on macOS based on unameTor Arne Vestbø2021-05-211-0/+7
| | | | | | | | | | | | | | | | | | | | | | | When dealing with a universal build of Qt, we would end up using the QT_ARCH as the architecture for user projects, but this architecture is always the primary one that Qt was configured with. Instead of relying on QT_ARCH, we start writing QT_ARCHS (plural) to qconfig.pri, based on CMAKE_OSX_ARCHITECTURES, and then use that to initialize QMAKE_APPLE_DEVICE_ARCHS. We then resolve the active arch using uname -m, matching what CMake does. We still feed all the available architectures to the Makefile or Xcode project, so that the user can build for any of the available architectures without needing a reconfigure. Fixes: QTBUG-93760 Change-Id: I0d338241ba4d944ca36d85371e9c4df7dbc4f269 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Enable UNICODE for all Qt targets and Qt consumers by defaultAlexey Edelev2021-05-213-8/+16
| | | | | | | | | | | | | | | | | | After discussion we decided to opt-out the UNICODE definintion behavior. To disable UNICODE in user projects the qt6_disable_unicode_defines function could be used. Amends 5b64e5950cf984abb7d47e0802bcb4b5a21e06fa [ChangeLog][CMake] Enables the UNICODE and _UNICODE definitions on WIN32 platforms by default for all cmake projects to reflect the qmake behavior. Use qt6_disable_unicode_defines function to disable the default unicode definitions. Pick-to: 6.1 Fixes: QTBUG-93895 Change-Id: Id70ff7dcf8c74f660ec851f8b950e1e3b94d9fb4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Do not expose Qt internals by the HEADER_MODULEsAlexey Edelev2021-05-201-1/+2
| | | | | | | | | | | | | | | | | | HEADER_MODULEs use the INTERFACE visibility to link libraries. This causes a transitional propagating of the Qt-internal compile definitions and options to the user targets. This commit avoids an implicit adding of the Qt::PlatformModuleInternal library to the HEADER_MODULEs and stops propagation of the Qt-internal compile definitions and options. If module wants the transitional propagation of some properties, this needs to be done explicitly. Amends 8b7894cb637d21d8fa9bd129849cd23462632d28 Pick-to: 6.1 Fixes: QTBUG-89951 Change-Id: Ia9cecc38bac98eb5bc6e47d288308b49813ab5ac Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Merge main and private targets of the internal modulesAlexey Edelev2021-05-207-83/+157
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In cmake, targets are used as an entity for modules. This causes a number of problems when we want to manipulate a module as a separate entity with properties associated with it. The _qt_internal_module_interface_name target property is introduced to represent the module entity. All modules write a name to this property, which will subsequently expand into the module name matched with the module name in qmake. The 'qt_internal_module_info' function is responsible for providing the correct values ​​for the module properties used when working with a module target. Unlike qmake, for internal modules in cmake it is expected that the Private suffix will be specified explicitly. In case the user wants to have a different module name, an additional argument MODULE_INTERFACE_NAME of the qt_internal_add_module function is introduced. This also changes the way how target dependencies are collected and resolved. Since the 'Private' suffix no longer means an unique identifier of the module 'Private' part, we look for the both Private and non-Private package names when resolving dependencies. TODO: This change doesn't affect the existing internal modules, so to keep compatibility with the existing code the existing internal modules create 'Private' aliases. The code that provides backward compatibility must be removed once all internal modules will get the proper names. Taks-number: QTBUG-87775 Change-Id: Ib4f28341506fb2e73eee960a709e24c42bbcd5ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add support for building and installing repo target setsJoerg Bornemann2021-05-204-0/+57
| | | | | | | | | | | | | | | | | | | | | | | Introduce the concept of repository target sets, which is a named set of targets within a Qt module repository. In a Qt repository, a repo target set 'qtfoo' can be defined in the top-level project file with qt_internal_define_repo_target_set(qtfoo DEPENDS Bar Baz) The DEPENDS argument specifies Qt components that need to be find_package'd when building the targets that belong to qtfoo. In subdirectory project files, use qt_internal_include_in_repo_target_set(qtfoo) to mark the file as belonging to the repo target set. To build and install a single repo target set, specify QT_BUILD_SINGLE_REPO_TARGET_SET=qtfoo when configuring the Qt repository. Change-Id: Ic9e6213e3225988fd561f315bc857ee44ff17420 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Introduce finalizer mode handling of static pluginsAlexandru Croitor2021-05-202-3/+187
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow linking all plugin initializer object libraries directly into the final target (executable or shared library). The finalizer mode is triggered when the project adds a call to qt_import_plugins, as well when the project has an explicit call to qt_finalize_executable or when it is defer called by CMake 3.19+. Otherwise the old non-finalizer mode is used, where each plugin initializer object library is propagated via the usage requirements of its associated module. A user can explicitly opt in or out of the new mode by calling qt_enable_import_plugins_finalizer_mode(target TRUE/FALSE) The implementation, at configure time, recursively collects all dependencies of the target to extract a list of used Qt modules. From each module we extract its list of associated plugins and their genex conditions. These genexes are used to conditionally link the plugins and the initializers. Renamed QT_PLUGINS property to _qt_plugins, so we can safely query the property even on INTERFACE libraries with lower CMake versions. QT_PLUGINS is kept for backwards compatibility with projects already using it, but should be removed in Qt 7. The upside of the finalizer mode is that it avoids creating link cycles (e.g. Gui -> SvgPlugin -> Gui case) which causes CMake to duplicate the library on the link line, slowing down link time as well as possibly breaking link order dependencies. The downside is that finalizer mode can't cope with generator expressions at the moment. So if a Qt module target is wrapped in a generator expression, it's plugins will not be detected and thus linked. Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: Ic40c8ae5807a154ed18fcac18b25f00864c8f143 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Build plugin initializers as object libsAlexandru Croitor2021-05-184-45/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of compiling the plugin initializers as part of a user project, pre-compile them as object libraries while building Qt. The installed object libraries can then be used with target_sources(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>) so that they are linked into the final executable or shared library via qt module usage requirement propagation. This reduces the build times of user projects. The link line placement of the object files should be correct for all linux-y linkers because the only dependency for the object files is Core and the Gui -> plugin -> Gui -> Core cycle does not hamper that from empirical observations. As a consequence of the recent change not to link plugin initialization object files into static libraries, as well not having to compile the files in user projects, we can get rid of the _qt_internal_disable_static_default_plugins calls in various places. A side note. Consider a user static library (L) that links to a Qt static library (Gui) which provides plugins (platform plugins). If there is an executable (E) that links to (L), with no direct dependency to any other Qt module and the intention is that the executable will automatically get the platform plugin linked, then (L) needs to link PUBLIC-ly to (Gui) so that the plugin usage requirements are propagated successfully. This is a limitation of using target_sources(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>) which will propagate object files across static libraries only if qt_module is linked publicly. One could try to use target_link_libraries(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>) which preserves the linker arguments across static libs even if qt_module is linked privately, but unfortunately CMake will lose dependency information on Core, which means the object files might be placed in the wrong place on the link line. As far as I know this is a limitation of CMake that can't be worked around at the moment. Note this behavior was present before this change as well. Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: Ia99e8aa3d32d6197cacd6162515ac808f2c6c53f Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* cmake: Add repository name to test labels for qt5 buildsTor Arne Vestbø2021-05-181-1/+7
| | | | | Change-Id: Icb23f2ea885f6d21bef80c587a431f7e9349f21b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Provide supported qt_internal_add_module() args via a functionCraig Scott2021-05-181-6/+46
| | | | | | | | | | This is to allow other repos like qtdeclarative to more easily pass through supported arguments to qt_internal_add_module() from their own functions. Task-number: QTBUG-88763 Change-Id: I965d593de4c6f9d5295a0d427c32dc3d5b1bb639 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Don't do plugin initialization for static librariesAlexandru Croitor2021-05-171-0/+7
| | | | | | | | | | | | | | | | | | | | Q_IMPORT_PLUGIN generates a global static symbol that initializes a plugin. If this symbol is added to a static library and the library is then linked to an executable, the linker decides that the symbol is unused (because nothing references it) and discards it. This means there's no point to compile the Q_IMPORT_PLUGIN containing files into static libraries. Change the generator expression we use for plugin propagation via associated modules to not compile and link the plugin initialization object file into a static library. Pick-to: 6.1 Task-number: QTBUG-80863 Change-Id: Ide32c0124c1e313c352a72280ce32ce9fbe8fff1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* wasm: make sure bind is compiler argumentLorn Potter2021-05-141-0/+1
| | | | | | Fixes: QTBUG-93713 Change-Id: I027caccb5c37bab529c80efac0b575a363be5f89 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: add an option to enable or disable versioned hard linkLi Xinwei2021-05-132-0/+8
| | | | | | | | | | | The option is called QT_CREATE_VERSIONED_HARD_LINK. By default, it is set to ON. Users can set this option to OFF to disable versioned hard link. Pick-to: 6.1 Fixes: QTBUG-93636 Change-Id: I0ffa1ee1c6bae1950df332fcce3152a861b33db0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix typo in FindWrapAtomic.cmakeJohn Zimmermann2021-05-121-3/+3
| | | | | | | | There was a D missing, we want to set CMAKE_REQUIRED_LIBRARIES Pick-to: 6.1 Change-Id: I7a76d60480ef7bff439f298fe85614d3b7e3ae88 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Add 'collect_targets' mode to __qt_internal_walk_libsAlexandru Croitor2021-05-111-13/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | Allow collecting all public dependency CMake targets starting from a given initial target. The new mode walks INTERFACE_LINK_LIBRARIES of a shared library or executable target, as well as the INTERFACE_LINK_LIBRARIES and LINK_LIBRARIES of a static library target. Each encountered target (checked with if(TARGET)) is added the output list. Note that the private dependencies of a non-static target (like a shared library or executable) are not walked by the new mode. Introduce a new function called __qt_internal_collect_all_target_dependencies which uses the new mode to collect the full private dependency list of a target. The final list only contains targets, so no linker flags or file paths. This list is useful to do further processing on the targets like extracting properties from them and running finalizers. Task-number: QTBUG-92933 Change-Id: I5d96cfa05722d65e2248a344a4f2b0f98a992817 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Make qt_internal_walk_libs available in public projectsAlexandru Croitor2021-05-1110-260/+267
| | | | | | | | | | | | | | | | | | Needed for the upcoming static plugin mechanism, where we have to extract the list of Qt module dependencies of a target and then extract the plugins associated with those modules. To do that we need to recursively collect the dependencies of a given target. Rename the moved functions to contain the __qt_internal prefix. Also rename the existing QtPublicTargetsHelpers.cmake into QtPlatformTargetHelpers.cmake to avoid confusion with the newly introduced QtPublicTargetHelpers.cmake. Task-number: QTBUG-92933 Change-Id: I48b5b6a8718a3424f59ca60f11fc9e97a809765d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Hide qt plugin static import source files in a dot folderAlexandru Croitor2021-05-111-1/+1
| | | | | | | | | To keep the build directory tidier. Task-number: QTBUG-92933 Change-Id: I27213185a78b292bda7ae34bbc8161d4b5583872 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Refactor handling of static pluginsAlexandru Croitor2021-05-116-116/+203
| | | | | | | | | | | | | | | | | | | | Extract common static plugin handling functionality into a separate QtPublicPluginHelpers.cmake file which is loaded by the Qt6 package. Split the code into smaller functions that will be re-used by each templated QtPlugins.cmake.in file, rather than copy pasting the same code into each QtFooPlugins.cmake file. As a drive-by, handle QtFeatures.cmake and QtFeaturesCommon.cmake as public helper files just like QtPublicPluginHelpers.cmake. This makes it clearer that the functions are available outside the internal Qt build and also provides a way for not dumping new helper functions into Qt6CoreMacros.cmake. Task-number: QTBUG-92933 Change-Id: Id816ef009b4fac1cd317d3ef23f21b3530028067 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-13 04:41:51 +0000