summaryrefslogtreecommitdiffstats
path: root/cmake/QtPluginHelpers.cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Create plugin initializers for static user pluginsAlexandru Croitor2021-08-241-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously we only created object library static plugin initializers for Qt plugins only, not user-project plugins. The reason was that if a user tried to install the plugin target via an export set, CMake would error out saying that the _init library is not part of the same export set. Introduce an OUTPUT_TARGETS option that would allow projects to get the name of the generated _init target, so they can install it if needed. This was already done for qt6_add_qml_module, so we just introduce the same option for qt6_add_plugin. Now user static plugins will have an _init target created, which will be propagated to consumers whenever the consumers link against the plugin itself. We also need an internal option to disable this propagation, because it's handled a bit differently for Qt plugins which can be linked either via finalizers or via usage requirements. Amends 91c65dd80cdd2de666448c14202c0c63718152b6 As a result of the implementation change, cleanup example projects to ensure that they build successfully (the important part is specifying the CLASS_NAME). Only plugandpaint works properly with both shared and static Qt builds. echoplugin works with a shared Qt build, but not a static one due to some assumptions in the C++ code about shared plugins. styleplugin doesn't seem to work properly neither with shared Qt builds nor static Qt builds, at least on macOS. But it builds fine. For some reason even if the plugin is found, the style is not applied. Amends 4caac1feea025b0ad496141e8f16ab88c04c2caa Pick-to: 6.2 Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: I6f631cda9566229b7a63992b23d7d7fa50303eeb Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Warn if qt_internal_plugin(target) does not end with 'Plugin'Kai Köhne2021-08-121-2/+7
| | | | | | | | | | | | | | The logic for linking plugins in a static build in Qt6*Plugins.cmake looks up plugins that are named Qt6*PluginConfig.cmake, and the file name is computed by the target name. Not naming the target 'Plugin' therefore means it won't be picked up in static builds. Pick-to: 6.2 Task-number: QTBUG-95731 Change-Id: Ic83a29d7c91492c302eb413a69577a0c550e1a1b Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Rename qt6_add_plugin TYPE option to PLUGIN_TYPEAlexandru Croitor2021-08-061-8/+18
| | | | | | | | | | | | | The intention is to remove TYPE as a keyword completely before 6.2.0 release, but in case if that's not possible due to the large amount of repositories and examples, just print a deprecation warning for now and handle both TYPE and PLUGIN_TYPE. Task-number: QTBUG-95170 Pick-to: 6.2 Change-Id: If0c18345483b9254b0fc21120229fcc2a2fbfbf5 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Apply bitcode flags to internal plugin object lib initializersAlexandru Croitor2021-07-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | All internal libraries, plugins, object libraries (resources, plugin initializers) need to be built with bitcode flags when targeting iOS. Internal here means all libraries added by qt_internal_add_X functions or associated with internal libraries. We didn't do that for plugin initializers, which were added not too long ago. Extract the logic that links to Qt::PlatformModuleInternal into a separate function to be used for object libraries. Use it for resources and plugin initializers. It will also be used in qtdeclarative for qml plugin initializers. Pick-to: 6.2 Task-number: QTBUG-95208 Change-Id: I366996078f5e9d1c2d2797f6b81c522ee99529e3 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Don't propagate -fapplication-extension to user projectsAlexandru Croitor2021-07-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | Both the compiler and linker -fapplication-extension flag should only be applied when building Qt's libraries (not executables). It's up to the user project whether their code will be restricted with application-extension-only APIs. In qmake that can be achieved by adding to the qmake project CONFIG += app_extension_api_only In CMake it can be achieved by either adding the compiler and link flags in the project directly (using target_X_options) or by setting the appropriate setting in the Xcode project when using the Xcode generator. Amends e189126f1ae1d2fa2ad0f95ee2c4aa72c770a97b Pick-to: 6.2 Task-number: QTBUG-95199 Change-Id: Ie7a764d460a89c7650391abff0fcc5abfcabef64 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Warn on any PUBLIC usage requirements specified for Qt pluginsJoerg Bornemann2021-07-121-1/+1
| | | | | | | | | | | | Repositories have been changed to be free of this warning. We're now changing the default of QT_WARN_PLUGIN_PUBLIC_KEYWORDS to ON. Set this variable to OFF to disable the warnings. Pick-to: 6.2 Change-Id: Ie37a4df1032f5b1e9152d970e8a14c574ed70241 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Don't generate .pri files for qml pluginsAlexandru Croitor2021-06-171-1/+5
| | | | | | | | | | | | | | | | | We didn't do it in Qt 5 times and it was accidentally done for Qt 6. There's no reason to generate them, the .pri files are only meant to be used for regular plugins so a project can do QTPLUGINS += foo. That mechanism is not needed for qml plugins which use qmlimportscanner instead. Furthermore the pri contents didn't contain a class name, so they couldn't be used anyway. Pick-to: 6.2 Change-Id: I6299fda21ece0f693a817ab558b45aa46b97e5ee Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Allow promoting the Qt libraries to be global targetsAlexandru Croitor2021-06-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | User projects can set the QT_PROMOTE_TO_GLOBAL_TARGETS variable to true so that the various imported targets created by find_package(Qt6) are promoted to global targets. This would allow a project to find Qt packages in a subdirectory scope while using those Qt targets from a different scope. E.g. it fixes errors like CMake Error at CMakeLists.txt:5 (target_link_libraries): Error evaluating generator expression: $<TARGET_OBJECTS:Qt6::Widgets_resources_1> Objects of target "Qt6::Widgets_resources_1" referenced but no such target exists. when trying to use a static Qt from a sibling scope. Various 3rd party dependency targets (like Atomic or ZLIB) are not made global due to limitations in CMake, but as long as those targets are not mentioned directly, it shouldn't cause issues. The targets are made global in the generated QtFooAdditionalTargetInfo.cmake file. To ensure that resource object libraries promoted, the generation of the file has to be done at the end of the defining scope where qt_internal_export_additional_targets_file is called, which is achieved with a deferred finalizer. Replaced all occurrences of target promotion with a helper function which allows tracing of all promoted targets by specifying --log-level=debug to CMake. Pick-to: 6.2 Fixes: QTBUG-92878 Change-Id: Ic4ec03b0bc383d7e591a58c520c3974fbea746d2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Build plugin initializers as object libsAlexandru Croitor2021-05-181-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Fix auto-linking of static plugins for non-QML in-tree testsAlexandru Croitor2021-04-221-13/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Certain repositories like qtsvg, qtimageformats and qtvirtualkyboard build plugins associated with Qt modules from other repositories (qtsvg's QSvgPlugin associated to qtbase's QtGui). When configuring in-tree tests in the same build folder as the repository, the test executables would not automatically link to these plugins. Fix this by recording the existence of such plugins in a separate property of the associated Qt module and only link them when both the test executable and plugin are from the same project (their PROJECT_NAME coincides). This is in addition to linking the plugins associated with the module where both are built in the same repository. The logic is a bit tricky and ensures that plugins are not accidentally initialized twice, so that in-tree tests work for both top-level and per-repo builds. As a drive-by, added a TODO explaining why in-tree tests that need to link to static QML plugins won't work (somewhat unrelated to this change). Amends 734d2cdbc4ff6db6b3df8fffbb23dbbb565c076b Amends b1fcdad9c9b9ad2bddd00f7301c8dd1159d523c2 Pick-to: 6.1 Task-number: QTBUG-87580 Change-Id: I3e1ff8166864f92dea931ec2ea34b6f56b4eec60 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix condition evaluation in plugin's DEFAULT_IF optionAlexandru Croitor2021-04-121-6/+6
| | | | | | | | | | | | Expand the condition without an extra negation. This fixes incorrect condition evaluation for conditions not enclosed in parenthesis. Pick-to: 6.1 Change-Id: I4923059b6b199676058091c23d51c9368daaebd0 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix duplicate symbol errors in Windows static super buildsAlexandru Croitor2021-04-121-18/+21
| | | | | | | | | | | | | | | | | | | | | | | | | qt_internal_add_executable has some special logic to link static plugins in order to avoid issues with link cycles on exported Qt module targets. This logic does not take into account if a plugin is a default plugin. On windows this caused duplicate symbol linking issues in static super builds, because both qwindows and qdirect2d define a subset of the same symbols. Make sure to only link to default static plugins. This will skip linking to qdirect2d because it's not a default qpa plugin and thus avoid linker issues. Amends 5807e1ae8168a5702ad0f6890d2b35223cfebdee Pick-to: 6.1 6.1.0 Fixes: QTBUG-92451 Change-Id: I56df2ce0201625088417de53038642518c1d3bbd Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Skip adding externally added plugins to the plugin meta-setsAlexey Edelev2021-04-081-3/+7
| | | | | | | | Plugin meta-sets are not visible outside of the module build tree, so there is no point in adding dependencies for externally added plugins. Change-Id: Ica5b29b57c032f4fc9b128172aaa806392e9e581 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Remove use of qt_internal_module_info from qt_internal_add_pluginAlexey Edelev2021-04-071-3/+1
| | | | | | | | | | | Plugin targets don't fit the requirements of the module but use the function associated to the module. The purpose of using qt_internal_module_info is to get the path to the top-level include directory. So there is no point in breaking the encapsulation rules to get a well-known directory. Change-Id: If3d2a31d4ec186929e3d662a79a1ae9eac988d1a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* wasm: add cmake build supportLorn Potter2021-04-011-1/+3
| | | | | | | | | | | | | | | | A few configure defines get changed: QMAKE_WASM_PTHREAD_POOL_SIZE is now QT_WASM_PTHREAD_POOL_SIZE QMAKE_WASM_TOTAL_MEMORY is now QT_WASM_INITIAL_MEMORY QMAKE_WASM_SOURCE_MAP_BASE is now QT_WASM_SOURCE_MAP_BASE device-option EMSCRIPTEN_ASYNCIFY=1 is QT_EMSCRIPTEN_ASYNCIFY=1 To create source maps for debugging. use device-option QT_WASM_SOURCE_MAP=1 Task-number: QTBUG-78647 Change-Id: If9f30cd7fb408c386d6d69b5f7b1beecf1ab44b5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Avoid using prohibited target property names with INTERFACE targetsCraig Scott2021-03-311-3/+3
| | | | | | | | | | | | | | | | | | | | CMake 3.19 removed the restrictions on allowable names for properties on INTERFACE targets. With earlier CMake versions (back to CMake 3.11), names for custom properties must begin with either a lowercase letter or an underscore. In 5807e1ae81 (Add plugins to Qt tools and executables for static builds, 2021-03-19), the names QT_REPO_PLUGIN_CLASS_NAMES and QT_REPO_PLUGINS were used, but in some cases, the targets on which they were being set are INTERFACE targets. Replace these with names that are supported with CMake 3.11 or later. Amends 5807e1ae8168a5702ad0f6890d2b35223cfebdee Task-number: QTBUG-91915 Pick-to: 6.1 Change-Id: Ife702a1fb339b190d46a8dafb380253219199ba6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Semi-handle non-current repo qt modules when creating pluginsAlexandru Croitor2021-03-311-12/+32
| | | | | | | | | | | | | | | | | | | | | | | | In the recent refactoring of qt_internal_add_plugin, a new target existence check was added when associating a plugin with a qt module. That check didn't account for a qualified qt module target name. This failed configuration of qtsvg which checked for the existence of a namespace-less 'Gui' in a per-repo build. Make sure to prepend the Qt namespace to the qt module name and also handle aliased target names. As a drive-by, add a TODO item to figure out how to link executables to plugins who's plugin type belong to a different repo, but both the executable and plugin are built in the current repo. Amends aa4a1006cbccbc180c600f9b4dc9e882bb5ed5ca Fixes: QTBUG-92235 Change-Id: I1c0f83672ab00f4702be9bad9a66ccc35e82f5c8 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 734d2cdbc4ff6db6b3df8fffbb23dbbb565c076b) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Fix plugin SKIP_INSTALL optionAlexey Edelev2021-03-291-5/+14
| | | | | | | | | | If SKIP_INSTALL option is specified for the qt_internal_add_plugin function the install_directory variable become empty and finalizer unable to call qt_finalize_plugin, because of lack of the second argument. It makes sense to use the INSTALL_PATH single argument instead. Change-Id: I2d4b40c8cf812a834c0e045569b45a649d339508 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Refactor qt_internal_add_plugin() and qt6_add_plugin()Craig Scott2021-03-291-51/+64
| | | | | | | | | | | | | | | | | | | | | | Remove code duplication by calling qt6_add_plugin() from qt_internal_add_plugin(). Separate out the public and internal arguments for the variables defined in QtBuild.cmake for these functions. Provide them via commands instead for greater robustness. This separation allows other Qt repos to access the appropriate set of keywords where they define commands that forward on to *_add_plugin() in their implementations. Retain the old variables for now to simplify the integration steps for updating other repos. The old variables can be removed once there are no more references left to them in any repo. Task-number: QTBUG-88763 Pick-to: 6.1 Change-Id: I0105523afd95995923bd20fc963d245bbb15d34d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add plugins to Qt tools and executables for static buildsCraig Scott2021-03-231-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In static builds, we cannot allow any part of the main build to make a call to find_package(Qt6...) where such a call may load a Qt6*Plugins.cmake file. That would add additional dependencies to the main module targets, setting up a circular dependency in the set of *Config.cmake files which cannot be resolved. This scenario would be triggered by per-repo builds or user projects. But Qt's tools and other executables still need to load some plugins in static builds. Sometimes a platform plugin may be enough, other times we may want all supportable plugins (e.g. Qt Designer). Therefore, add all plugins we can identify as relevant for an executable that is part of the Qt build, but add them directly to the executable without affecting the linking relationships between the main module libraries. Also remove the now unnecessary check for QT_BUILD_PROJECT_NAME in top level builds because there should be no difference between per-repo and top level builds any more (as far as linking static plugins is concerned). Examples that build as part of the main build will still build successfully after this change, but they will not run if they require a platform plugin. Examples need to be moved out to a separate build where they can call find_package(Qt6) without QT_NO_CREATE_TARGETS set to TRUE to be runnable (see QTBUG-90820). Fixes: QTBUG-91915 Pick-to: 6.1 Change-Id: I8088baddb54e394ca111b103313596d6743570ba Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Fix build of QTuioTouchPlugin with Makefile generator on macOSJoerg Bornemann2021-03-111-2/+8
| | | | | | | | | | | | | | | | | For each plugin, we create a custom target with it's OUTPUT_NAME such that one simply can do 'ninja qtuiotouchplugin' to build it. QTuiTouchPlugin has qtuiotouchplugin as OUTPUT_NAME, which is problematic with Makefile generators on case-insensitive file systems. See CMake upstream issue #21915 for details. Work around this issue by not creating the custom target in this situation. Pick-to: 6.1 Fixes: QTBUG-84342 Change-Id: Id9a6cf0a01c179d5c93da4146e393cf00153ac4f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* qtdeclarative now directly handles more qml-specific logicCraig Scott2021-03-101-6/+0
| | | | | | | | | | | | | | | | | Associated changes in the qtdeclarative repo now ensure that arguments for qml plugins are handled on the calling side. This reduces the qml-specific logic needed in qtbase and gives qtdeclarative clearer control over qml build and install locations. As part of that work, the INSTALL_LOCATION keyword used in qt_internal_record_rcc_object_files() has been renamed to INSTALL_DIRECTORY to make it consistent with the keyword used for the same concept in other commands. Pick-to: 6.1 Change-Id: Iebd319899f63d79fbe15ce965b84ce324c28a508 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Make qt_get_module_for_plugin() internal and do what its name saysCraig Scott2021-03-021-12/+7
| | | | | | | | | | | | | | | | | | Contrary to its name, this command was also setting a target property. Since it was only called in one place and that caller can just as easily set the property instead, rename the command to make clear its internal nature and refactor it so that the caller is responsible for setting that property instead. Also make it an error rather than just a warning if the command is used for a target that doesn't belong to any module. Since this is now unambiguously an internal command, we should always expect the target to belong to a module. Pick-to: 6.1 Change-Id: I929a652ddd482653868fc9df887f38f4bc7f35d9 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* cmake: Don't give plugins PUBLIC usage requirementsCraig Scott2021-02-241-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | The pro2cmake.py conversion script faithfully reproduced the .pro files for the plugins, which specified the libraries as public. But in CMake, the implications of this are that public usage requirements should then be propagated to consumers. We don't expect any consumers, since a plugin is created as a MODULE library in CMake, so for Windows we don't even have an import library to link with. The only exception to this is for static builds where plugins are created as STATIC libraries instead, but only in certain controlled situations do we then link to plugins. Even then, usage requirements are not expected to propagate to the consumers, so these relationships should always be specified as private. This change warns on any PUBLIC usage requirements specified for a plugin. This check is disabled by default to avoid spamming CI builds for repos that haven't been fixed yet. The check can be enabled by a CMake cache option, which is intended for developers to use locally when fixing this issue in other repos (all plugins in qtbase should not trigger this warning as a result of changes in this commit). Task-number: QTBUG-90819 Pick-to: 6.1 Change-Id: I09f2c8da77db1193ad3370f85d367dfc6ab7b9a6 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Clear non-relevant CMake compiler flagsAlexey Edelev2021-01-271-3/+2
| | | | | | | | | | | | | | | | Add internal function to cleanup compiler flags out of the CMAKE_xxx_FLAGS_xxx variables. Use introduced interface to clear the '/EHsc' flag for the MSVC compiler family. This adjusts the CMake behavior to the qmake one. Change the 'EXCEPTIONS' option handling in helper functions. Add ability to add enabling and disabling exception flags. Previously it was only possible to add disabling exception flags. Fixes: QTBUG-89952 Change-Id: I60d47660a97ae9b5a1d1f4107d352c9e97890144 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Disable static plugin imports for non-executable targetsAlexandru Croitor2020-12-081-1/+1
| | | | | | | | | | | | | | There is no point in generating cpp files containing Q_IMPORT_PLUGIN() macro calls for non-executable targets like modules, plugins and object libraries in a static Qt build. It causes unnecessary compiling of 10+ files for each of those targets. In a static Qt build, plugin imports should only be done for executables, tools and applications. Pick-to: 6.0 Change-Id: Ied90ef2f6d77a61a093d393cfdf94c400284c4f0 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Enable NEW policies by CMake version with a global defaultCraig Scott2020-12-071-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a CMake release introduces a new policy that affects most Qt modules, it may be appropriate to make each module aware of that newer CMake version and use the NEW policy without raising the minimum CMake version requirement. To reduce the churn associated with making that change across all Qt modules individually, this change allows it to be updated in a central place (qtbase), but in a way that allows a Qt module to override it in its own .cmake.conf file if required (e.g. to address the issues identified by policy warnings at a later time). The policies are modified at the start of the call to qt_build_repo_begin(). For commands defined by the qtbase module, qtbase needs to be in control of the policy settings at the point where those commands are defined. The above mechanism should not affect the policy settings for these commands, so the various *Config.cmake.in files must not specify policy ranges in a way that a Qt module's .cmake.conf file could influence. Starting with CMake 3.12, policies can be specified as a version range with the cmake_minimum_required() and cmake_policy() commands. All policies introduced in CMake versions up to the upper limit of that range will be set to NEW. The actual version of CMake being used only has to be at least the lower limit of the specified version range. This change uses cmake_minimum_required() rather than cmake_policy() due to the latter not halting further processing upon failure. See the following: https://gitlab.kitware.com/cmake/cmake/-/issues/21557 Task-number: QTBUG-88700 Pick-to: 6.0 Change-Id: I0a1f2611dd629f847a18186394f500d7f52753bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Generate less pri files and mark header modules as no_linkCristian Adam2020-11-201-5/+6
| | | | | | | | | | | Plugins will no longer get .pri files generated in non-static builds. Header modules are now marked in the .pri files as CONFIG += no_link. Pick-to: 6.0 6.0.0 Fixes: QTBUG-88221 Change-Id: I06e31fa970ad021261c43ca3acd88055cc4c9555 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Add handling of PLUGIN_EXTENDS for generic pluginsAlexey Edelev2020-11-091-3/+2
| | | | | | | | | | Modify pro2cmake converter to add extra argument to qt_internal_add_plugin. DEFINE_IF FALSE is added to generic plugins those had "PLUGIN_EXTENDS = - " specified in .pro files. Fixes: QTBUG-87861 Change-Id: I9269df19a32a088f5261f50e7ffff6d29c3d605f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Add version information to Qt plugin DLLsJoerg Bornemann2020-11-061-0/+4
| | | | | | | | | | Tools and library DLLs already have version information embedded. Add the missing _qt_internal_generate_win32_rc_file call for plugins. Fixes: QTBUG-87747 Change-Id: I619948f4066ce229d41e8b93f125751e1d28e26c Reviewed-by: Cristian Adam <cristian.adam@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake Build: Enable separate debug info for all target typesCristian Adam2020-11-041-0/+2
| | | | | | | | | | | | | Now all shared libraries and executables will get .debug files on the platforms that support FEATURE_separate_debug_info With the directory property _qt_skip_separate_debug_info certain targets can retain the debug symbols in the binary e.g. lupdate with MinGW 8.1.0 will cause objcopy / strip to fail. Fixes: QTBUG-87015 Change-Id: I03b106e68ef0a42011d1ba641e6f686b2e7b7fb4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Cleanup module and plugin define situationAlexandru Croitor2020-10-301-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The QT.<module>.DEFINES assignment in pri files needs to take into account the module name when computing the define name. This is the MODULE value that qmake specifies. In CMake that would be the value of CONFIG_MODULE_NAME. Previously the value of the define was computed in qt_internal_module_info() without taking into account the module name. While qt_internal_module_info() ended being used also for plugins and other target types, the defines computed by it were meant to be used only for Qt modules. Thus remove the <result>_define assignment from qt_internal_module_info and move its computation directly into qt_internal_add_module, taking into account the value of CONFIG_MODULE_NAME. The only other use of module_define was in qt_internal_add_plugin but that was merely a long overdue copy-paste error, qmake doesn't propagate QT_FOO_LIB defines for plugins. As result, a define special case in testlib is not needed anymore, because the define is now computed properly. Finally, QT_FOO_LIB should not be used while building the Qt module itself, so instead of using PUBLIC_DEFINES option of qt_internal_extend_target, use target_compile_definitions(INTERFACE) directly. Change-Id: I4d44f7461bac2f0c09aec3e995d02dfe36e00883 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix target dependency cycle regarding qpa plugins in qtwaylandAlexandru Croitor2020-10-261-4/+16
| | | | | | | | | | | | | | | | | | | | | | | With the introduction of the new 'default_qpa_plugins' custom target, a target dependency cycle occurred in qtwayland: qtwaylandscanner -> default_qpa_plugins -> a wayland qpa plugin -> WaylandClient -> qtwaylandscanner The issue is twofold: - default_qpa_plugins accidentally depended on non-qpa plugins. - All qpa plugins were enabled by default, including the wayland ones. Fix the default_qpa_plugins target not to depend on regular non-qpa plugins. Also fix qpa plugins not to be enabled by default, but instead only choose one qpa plugin to be the default (via evaluating the DEFAULT_IF) condition. Amends df9c7456d11dfcf74c7399ba0981a3ba3d3f5117 Change-Id: I22cd2c72f6b75be54263fd21097258bd179e3616 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Fix deprecation defines not being set properlyAlexandru Croitor2020-10-231-1/+1
| | | | | | | | | Instead of propagating the deprecation wranings, we compiled all code with -Ddeprecations. Change-Id: I0233ddc85bdbdcb93d366073b2cea5d47bdbe52a Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Add convenience custom targets to build Qt pluginsAlexandru Croitor2020-10-221-0/+8
| | | | | | | | | | | | | | Add 3 new convenience custom targets: 'qt_plugins', 'qpa_plugins' and 'qpa_default_plugins'. Additionally, if we detect that an internal executable / test links against Gui, add a dependency on the 'qpa_default_plugins' custom target, so that if a developer configures Qt for the first time and then calls ninja 'tst_foo_check', we ensure the test will launch successfully because the default QPA plugin will also be built. Change-Id: If6dd70844b5effdf8a293f65f8785855cc85b132 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Install PDB debug info for MSVC buildsAlexandru Croitor2020-10-061-0/+1
| | | | | | | | | | | | | | | Supports installing linker generated debug info for shared libraries and executables, as well as compiler generated debug info for static libraries. Works with Ninja Multi-Config as well, with the caveat that the files are installed optionally, aka the install rule will not error out if a pdb file is not present. This is necessary, because it's not possible to create per-config install rules properly. Fixes: QTBUG-87006 Change-Id: I95e91a6557eb0ee0f882103be54cd38795c349f7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix build of Release user projects against RelWithDebInfo QtJoerg Bornemann2020-09-251-0/+4
| | | | | | | | | | | | | | | | | | | | | Building a user project in Release configuration against a Qt built with CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project being linked against the Debug Qt libraries. This is especially painful with MSVC where debug and release runtimes are incompatible. We now create *AdditionalTargetInfo.cmake files along the exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties to the values of the release config Qt was built with. User projects built with an unknown configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a release Qt. This can be controlled by setting the variable QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user project. Fixes: QTBUG-86743 Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake Build: Add support for -qtlibinfix configure parameterCristian Adam2020-09-231-1/+1
| | | | | | | | | Rename all libQt6*.so to libQt6*<infix>.so Task-number: QTBUG-85438 Change-Id: I4b91ffaaec7bea61454b0d3c794c77f2d0868d54 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Rename internal functions to contain qt_internalAlexandru Croitor2020-09-231-1/+1
| | | | | | | | | | Offer compatibility wrapper functions until we update all of the Qt repos to use the new names. Task-number: QTBUG-86815 Change-Id: I5826a4116f52a8509db32601ef7c200f9bd331de Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* CMake: Split QtBuild.cmake into smaller filesAlexandru Croitor2020-08-141-0/+308
QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-26 08:53:46 +0000