aboutsummaryrefslogtreecommitdiffstats
path: root/src/qml/Qt6QmlBuildInternals.cmake
Commit message (Collapse)AuthorAgeFilesLines
* Purge remaining support for SKIP_TYPE_REGISTRATIONFabian Kosmale2024-05-101-1/+0
| | | | | | | Change-Id: Ibbb3fed58d0fcd8c3e7f99b9a1150a24ab147620 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
* Generate qmldir files for extra directories with QML filesUlf Hermann2024-04-031-0/+12
| | | | | | | | | | | | | | | | Those qmldir files contain only a prefer directive for the canonical resource location of the module. This way, any time another component from the implicit import is requested, it will not be located in the extra directory (where it probably doesn't exist), but instead in the canonical location. Since people may have manually written qmldir files with different content in those places, or worse, relied on the other components to be inaccessible, we need a new policy to opt into this. Fixes: QTBUG-111763 Change-Id: If236feb7dd7c8d704b813ea56482ff758799d0a7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* CMake: Duplicate backing library metatypes to its associated pluginAlexandru Croitor2023-08-041-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | qmltyperegistar and other tooling expect a list of foreign metatypes derived from the full set of dependencies of the target it's processing. If a target was linking to a qml plugin, and not its backing library, the metatypes of the backing library were not passed to the tooling. The mechanism by which the metatypes are collected is via CMake's INTERFACE_SOURCES, and because the qml plugin links PRIVATEly to its backing library, in the chain app <- plugin <- backing lib the backing lib's interface sources were not passed to app. To work around this, use new qtbase api to duplicate the metatypes of the backing library to its associated qml plugin's INTERFACE_SOURCES, thus avoiding the issue. This is the best we can do given the CMake limitation of not being able to transitively propagate values of any custom property and without relying on finalizers. See https://gitlab.kitware.com/cmake/cmake/-/issues/20416 Fixes: QTBUG-115152 Change-Id: I8a1652a9b12bad01abce38bb6f381949eaa1feab Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Retire the qt_parse_all_argumentsAmir Masoud Abdol2023-01-201-2/+2
| | | | | | Task-number: QTBUG-99238 Change-Id: Ia11c9cbd7c06347319ab3674ec0cd8da0214747e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add explicit dependency on 'Qml_sync_headers' for QML modulesAlexey Edelev2022-10-131-0/+7
| | | | | | | | | | | | | | | | Add dependency on 'Qml_sync_headers' for all QML modules that are built in the qtdeclarative build tree. 'moc' requires QtQml/qqmlextensionplugin.h to process IID in the generated plugin source code. Since the '_autgen/timestamp' target doesn't have the 'Qml_sync_headers' target in its dependency chain, the header file is not created by syncqt before the 'moc' run. We need to make this explicitly, because CMake doesn't add the main target dependencies to the dependency list of the '_autgen/timestamp' target. Change-Id: I1a199b4044e1dd9caddf7c0a9d75d59860893f60 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Change the license of all CMakeLists.txt and *.cmake files to BSDLucie Gérard2022-09-071-1/+1
| | | | | | | Task-number: QTBUG-105718 Change-Id: Id89ed14990804a5024183e75382cc539d4293da1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Remove __QT_INTERNAL_INSTALL_METATYPES_JSON optionJoerg Bornemann2022-07-111-1/+0
| | | | | | | | | | | ...from qt6_add_qml_module and _qt_internal_qml_type_registration. This option was used to pass __QT_INTERNAL_NO_INSTALL to qt6_extract_metatypes. That option is a no-op by now and is bound to be removed as well. Change-Id: Id2094a12a40340252177afde700b0569683c003b Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* CMake: Remove support for the deprecated CLASSNAME keywordJoerg Bornemann2022-07-111-15/+0
| | | | | | | | | | ...in qt6_add_qml_module and qt_internal_add_qml_module. [ChangeLog][QtQml] The deprecated CLASSNAME argument of qt_add_qml_module has been removed in favor of CLASS_NAME. Change-Id: I55b5e5bda10d0e416e3c3c6f381245dd5df0ff29 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Add license headers to cmake filesLucie Gérard2022-07-081-0/+3
| | | | | | | | | | | | CMakeLists.txt and .cmake files of significant size (more than 2 lines according to our check in tst_license.pl) now have the copyright and license header. Existing copyright statements remain intact Task-number: QTBUG-88621 Change-Id: I72c89a98c42bbc9234d8495e9e503bec81d11037 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Remove qmltc compilation command in favor of qt_add_qml_module()Andrei Golubev2022-05-311-52/+7
| | | | | | | | | | | | [ChangeLog][CMake] The qmltc compilation functionality provided by qt6_target_compile_qml_to_cpp() is merged into qt6_add_qml_module() command and is available through ENABLE_TYPE_COMPILER argument. The qt6_target_compile_qml_to_cpp() function does nothing and is left only to highlight that users must migrate away from it. Fixes: QTBUG-100215 Change-Id: Ie7d6b82564dff86176194fce35039ba0d93c0977 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* qmldir: Allow for specifying default importsMaximilian Goldstein2022-02-141-0/+1
| | | | | | | | | | | | | | | | | Adds the option to specify default optional imports in qmldir for tooling to load. Previously we would just load all entries. This allows code that that relies on modules utilizing optional imports (i.e. everything utilizing QtQuick.Controls) to still be supported in a limited capacity. This change also adds the necessary CMake API to add these entries to qmldir files. It also disables loading optional imports by default and only leaves them enabled for qmllint. Change-Id: Iff6aaac9cb0ec72b7a2853b60840a4d28c84aa25 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Move registrations functions into the Qt namespaceUlf Hermann2022-02-011-0/+5
| | | | | | | | | | | It's high time we do this. We should not clobber the global namespace with type registration functions if the user has explicitly provided a namespace for Qt. Change-Id: Ibac49cb1c8976e65ea15d7a07d25ea1a5325a60a Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* qmltc: Rename CMake command's argument FILES -> QML_FILESAndrei Golubev2022-01-261-1/+1
| | | | | | | | | This way we make it consistent with qt_add_qml_module() Fixes: QTBUG-100214 Pick-to: 6.3 Change-Id: I9f38a8ba3dec978ccdf4ea937ff662ae2449e582 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Pass C++ sources to pre-created qml module targetsAlexandru Croitor2022-01-201-0/+3
| | | | | | | | Previously they were silently discarded. Pick-to: 6.2 6.3 Change-Id: I3ab4d050ea4649dec7e53f27c8044037bb49cddc Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Move QObject and QQmlComponent into builtinsMaximilian Goldstein2021-12-171-0/+2
| | | | | | | | | | | | | | | | | | | | | | Previously we had two versions of QObject and QQmlComponent: a hand-written version in bultins and one that is generated from QtQml. We now move the QtQml version into builtins in order to allow for representing the JavaScript extensions that are present in these types. We also add some logic so that unused types will still react properly despite the fact that those components are no longer in QtQml. This is done by introducing the concept of static modules. These are modules that have side effects beyond simply provinding components. This applies both to when some components are in builtins instead of QtQml or when the global object is modified in some way (i.e. by adding an image provider). This is a tooling-only concept and does not affect how these modules are handled at runtime. Fixes: QTBUG-99025 Change-Id: Ifacaa836e4d2eef0521494f5a41363e053c90007 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Use qmltc compiler prototype as a fallback implementationAndrei Golubev2021-12-171-1/+1
| | | | | | | | | | Task-number: QTBUG-91927 Task-number: QTBUG-96041 Task-number: QTBUG-84368 Pick-to: 6.3 Change-Id: I47320b5f3ed8efff6fb234778df5fae5be5b64f2 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* qmltc: support user-specified namespaces in the generated codeAndrei Golubev2021-11-161-0/+52
| | | | | | | | | | | | | | | Already during the prototyping phase, conflicts in class names were encountered within Qt code base. Those could be avoided by namespaces. Initial qmltc logic was using meaningless "q_qmltc" namespace, so let's improve that by allowing user-specified namespaces + making Qt's own QML files (compiled to C++) being available under QT_NAMESPACE. The latter is achieved by providing (and using) the internal version of a qmltc-invoking function Task-number: QTBUG-84368 Task-number: QTBUG-96040 Change-Id: I99cdf1baba8838c093b6b469f6744869f72af093 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* qt_add_qml_module: Add FOLLOW_FOREIGN_VERSIONING optionMaximilian Goldstein2021-10-291-0/+6
| | | | | | | | | | This option allows modules to follow the versioning scheme of their foreign base types when it comes to exposing revisioned properties. It is enabled it by default for our internal Qt modules. Task-number: QTBUG-91706 Change-Id: Ie2a660289d2b4c14800f3394321898eae3718425 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* CMake: Use modified target name as base name for internal qml pluginsAlexandru Croitor2021-09-081-7/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using only the last dot component of the URI as the plugin base name causes issues when an app that uses QtQuickControls2 is macdeployqt'ed. The qqc2 impl plugins all have "impl" as the last URI component and thus they all use "impl" as the base name. macdeployqt tries to copy all of the plugins into a flattened PlugIns/quick folder, which ends up copying only one of the files. User qml plugins use the plugin target name as the plugin base name and plugin file name on-disk. There shouldn't be a reason for internal qml plugins to deviate too much from that. Adjust the internal qml plugin name to use the plugin target name with "plugin" suffixed at the end, but make sure to remove any existing "plugin" from the target name if it already exists, so we don't end up with double "plugin" in the base name. Amends a25f650c317e4886007a8beb0e9f2f7e973e6e7c Pick-to: 6.2.0 6.2 Task-number: QTBUG-95140 Task-number: QTBUG-96261 Change-Id: If6096e88bf2da3de081d68fad2e70cef5a0b18af Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Allow QML plugin's CMake target name to be specified for qmldir fileCraig Scott2021-08-201-4/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | The current code assumes that the basename of the QML plugin is the same as the CMake target it corresponds to. This won't be the case for installed Qt packages due to the installed name including a namespace. It also won't match when a Qt library infix is used. The current code works around the former by trying to heuristically work out whether a namespaced Qt target exists for the plugin. The Qt library infix is more problematic because the plugin target name won't include the infix whereas the plugin library basename will. Address both of those issues by adding an internal option INSTALLED_PLUGIN_TARGET to qt6_add_qml_module() which allows the installed target name to be provided. When included in a qmldir file, qt6_import_qml_plugin() will use that name, otherwise it will fall back to using the plugin library's basename, as per the current behavior. The option may become public in the future, but for now it is only for Qt's internal use for the 6.2 release. Fixes: QTBUG-95140 Pick-to: 6.2 Change-Id: I5a057c80b70ee802c0f0840e9eea2e579193d126 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Don't install metatypes json files for user qml modulesAlexandru Croitor2021-08-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We shouldn't install metatypes json files for user created qml modules without allowing the project to say where they should be installed. Instead we should introduce new API to allow extracting the created json files so the user project decides where to install the files, similar how we would do it for other artifacts like the qmldir file or qmltypes file. Because it's too late to introduce such API for 6.2, disable installation of the files for user projects, but keep it for Qt provided qml modules. Once qt6_extract_metatypes in qtbase is fixed not to install the files by default, we should remove the newly introduced internal options and use a better mechanism for piping through when and where the files should be installed. Amends 1c4ba17015fe99da48ce73fab75ecc60cf9cb975 Pick-to: 6.2 Task-number: QTBUG-95845 Change-Id: Id8f6cd6d06aa58d42c72f62ef7458cfaf244b2cd Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Remove dead example-specific metatypes installation codeAlexandru Croitor2021-08-181-8/+0
| | | | | | | | | | | | | | | | | | | | | | | All projects (including examples) have ported away from using INSTALL_LOCATION and thus setting the QT_QML_MODULE_INSTALL_DIR property as part of the work done in 1c4ba17015fe99da48ce73fab75ecc60cf9cb975 Thus the work around to install the example metatypes files is not needed anymore. Furthermore qt6_extract_metatypes will be modified to not install json files by default anymore because the public API should not be handling that. Remove the dead code. Amends ee72ba123894bb92bcdd448d8a08eb1504d043eb Pick-to: 6.2 Task-number: QTBUG-95845 Change-Id: I0cfb4424cb79a059a2ecc337c9e4603b09154c63 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Use renamed qt6_add_plugin PLUGIN_TYPE optionAlexandru Croitor2021-08-101-1/+1
| | | | | | | Task-number: QTBUG-95170 Pick-to: 6.2 Change-Id: I6126387bcfc8c93211d782edd9fc127fba88f66f Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* Add NO_PLUGIN option to qt6_add_qml_module()Craig Scott2021-08-031-3/+6
| | | | | | | | | | | | | | | | | | | | The new option allows the caller to state more clearly that they do not want a plugin at all. Previously, the NO_CREATE_PLUGIN_TARGET option had to be given to prevent the command from trying to create a plugin target, but that option is meant for when the project will create the plugin target later. Now that the caller has a way to explicitly say they don't want a plugin, require PLUGIN_TARGET to be given if NO_CREATE_PLUGIN_TARGET is present. This forces the project to provide the name of the plugin target that they will be responsible for creating. Fixes: QTBUG-95141 Pick-to: 6.2 Change-Id: I84e036074f3e2785f17a8d33ad87ee0b7e016173 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Improve consistency of QML module target propertiesCraig Scott2021-08-031-1/+1
| | | | | | | | | | | Having more consistent property naming will make querying QML module information simpler (to be implemented in follow-up work). Task-number: QTBUG-95024 Pick-to: 6.2 Change-Id: I994742ebb1baab48ce31ec7a9371c9241e0847a3 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* Add internal getter for qml_module_keywords cmake functionMichal Klocek2021-07-271-44/+57
| | | | | | | | | | | | | | | | Follow pattern from qtbase and add getter for keywords, this allows to wrap add_qml_module function and filter some options in other modules. This is currently need to fix top level builds for webengine, which are used by RTA builds. Task-number: QTBUG-95152 Task-number: QTBUG-94922 Pick-to: 6.2 Change-Id: I7d9c206e61a99154c45eb188145c2bdee6820665 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Make TARGET_PATH an internal option for QML CMake commandsCraig Scott2021-07-261-6/+3
| | | | | | | | | | | | | | | | | TARGET_PATH should always be computed from the URI. In the past, there were some rare temporary cases where it was slightly different to assist with transitioning some existing QML modules. No internal uses of overriding the TARGET_PATH remain now though and user projects should always use a TARGET_PATH based on the URI. Keep the implementation in the public command in case an unexpected use case for it arises, but make it clear that it is now an internal option. Also remove it from qt_internal_add_qml_module() since we know it is not needed there now. Fixes: QTBUG-95083 Pick-to: 6.2 Change-Id: I75928fc194b5da64424ec8a838c1db4c0441edcf Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* CMake: Apply bitcode flags to internal qml plugin initializersAlexandru Croitor2021-07-221-0/+4
| | | | | | | | | | | | | | | | | | | 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 qml plugin initializers, which were added not too long ago. Use the newly introduced helper function in qtbase to do so. Pick-to: 6.2 Task-number: QTBUG-95208 Change-Id: Ia005e0b2d4673b01b6c6a0f21bb75756708fed2a Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* CMake: Change the default of OUTPUT_DIRECTORY for qt6_add_qml_module()Craig Scott2021-07-201-1/+2
| | | | | | | | | | | | | | | | | | | | | | | The new default is now controlled via a new QT_QML_OUTPUT_DIRECTORY variable. If that isn't set, the fallback assumes the source directory structure follows the URI structure and uses ${CMAKE_CURRENT_BINARY_DIR} instead. This pattern means more projects will have working import paths for qmllint and possibly other tools out of the box. There should also be fewer cases where the OUTPUT_DIRECTORY option needs to be used in calls to qt6_add_qml_module(). The QT_QML_OUTPUT_DIRECTORY variable facilitates the scenario where QML modules might be distributed across different parts of the source directory hierarchy, but once collected under a common base point defined by QT_QML_OUTPUT_DIRECTORY, they form a coherent set of QML modules whose subdirectory structure below that base point follows their TARGET_PATH. Fixes: QTBUG-94164 Fixes: QTBUG-95081 Pick-to: 6.2 Change-Id: I82864c361a2b34f7f1484cdbda0d9b64b34b9950 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* CMake: Remove deprecated NO_CREATE_BACKING_TARGET optionAlexandru Croitor2021-07-011-2/+0
| | | | | | | | All repos using it have been adjusted. Pick-to: 6.2 Change-Id: I8156d94f81f0d77496d9147b8b5b373e1a897929 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Assign output targets to appropriate export setsAlexandru Croitor2021-06-251-9/+46
| | | | | | | | | | | | | | | | | | Plugin initializer targets should go to the plugin export set. The rest of the output targets (resources and qmlcache object libraries for now) should go the main backing target export set. Also generate the missing additional target info files for each export set. Pick-to: 6.2 Task-number: QTBUG-93257 Task-number: QTBUG-92933 Change-Id: I0b13a15459f3c6379bf87de1819fda97ade8c416 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Allow using an existing target as a backing targetAlexandru Croitor2021-06-181-5/+3
| | | | | | | | | | | | | | | | | | | This was previously achieved by passing a NO_CREATE_BACKING_TARGET internal option to qt_internal_add_qml_module. Now it's just a conditional check to only create the backing target if it doesn't exist yet. This aligns with the behavior of the public qt_add_qml_module function. The old option is deprecated and will be removed once all repos mentioning it don't use it anymore. Amends cb293ee3afea3fe0cfabee58b4d34c278f17b709 Pick-to: 6.2 Change-Id: Ifd478a5495b36c7ba127d4b8bea2ec1225035744 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* CMake: Adjust QML plugin class name auto-computingAlexandru Croitor2021-06-181-6/+8
| | | | | | | | | | | | | | | | | | | | | | The recent 602d26c38f3767be9bec25302c93fc155c4dce59 change in qtbase is now requiring that CLASS_NAME is always set for qml plugins, to ensure that in static builds we can pre-build a plugin initializer object library. Split out the uri escaping and class name generation code into separate functions. Ensure that the class name is auto-generated by qt_internal_add_qml_plugin if it wasn't manually specified. Pass that value to the qt_internal_add_plugin function. Remove comment about not passing the CLASS_NAME. Task-number: QTBUG-93257 Task-number: QTBUG-92933 Change-Id: I8aa482a7da3a59f5a2213a630ff0be70506efe11 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Add RESOURCES argument to qt_add_qml_moduleUlf Hermann2021-06-161-4/+5
| | | | | | | | | | | This way you can pass QML-related resources without triggering a warning. Pick-to: 6.2 Change-Id: I4b7db5007f1f2ecf0eb556bc4e5bc67f8ac9148d Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
* Install .qml files from source dir and honor their resource aliasCraig Scott2021-06-171-5/+17
| | | | | | | | | | | | | | | | | | | | | | | For targets that are built as part of Qt, we currently require all .qml files to be passed to qt_internal_add_qml_module(). We can use that to iterate over the set of qml files and access their source file properties at configure time. The previous approach tried to use the list obtained at generate time, but the source file properties (and therefore their resource aliases) were not accessible and the install locations assumed no resource path or alias. By installing from the source dir, we also address the dependency issue where an install wouldn't cause the build dir copies to be updated. The install target will always install the latest source files with this change. Fixes: QTBUG-94519 Fixes: QTBUG-94520 Pick-to: 6.2 Change-Id: I6a97a9631ff77c3f7696899a347b83c2eb4b0ca4 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Remove compatibility functionsAlexandru Croitor2021-06-161-11/+0
| | | | | | | | | | | | | | | | All our qt5.git repos are marked with QT_NO_INTERNAL_COMPATIBILITY_FUNCTIONS There are still some marketplace repos like quicktreeview that don't have it, but those should be fixed separately. The point is we don't want to override the public qt_add_qml_module function with the compatibility one. Pick-to: 6.2 Change-Id: I7959025acbf30ac94b6c20799089996a66c06fc2 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* CMake: Allow using existing backing target for a new qml moduleAlexandru Croitor2021-06-041-19/+34
| | | | | | | | | | | | | | | | | | qtwayland has a case where the backing target is always created by qt_internal_add_module and it is promoted to a qml module conditionally only if Qt::Qml target exists. qt_internal_add_qml_module always tries to create a backing target. Allow passing an internal only NO_CREATE_BACKING_TARGET option to re-use an existing target, while still applying necessary qml-specific install rules. Amends 1c4ba17015fe99da48ce73fab75ecc60cf9cb975 Task-number: QTBUG-91621 Change-Id: I15f4da4fd3a3ab991c78e8c77975677a0d820fd5 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Refactor and update qml CMake APICraig Scott2021-06-041-65/+224
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The existing CMake API for qml modules had a number of shortcomings. Refactor it to achieve the following: - Clearly separate public and internal aspects. - Re-use code from qtbase for adding plugins and module targets rather than reimplementing close variations. - Provide more robust and complete support for qmllint, qmlcachegen and automatic generation of qmldir files. - Reduce the steps needed for more common scenarios. - Encourage the use of separate backing library and plugin targets. - Automatically generate the plugin class .cpp file where possible. - Specify .qml files directly through qml-specific API elements rather than assuming they can be extracted out of a set of resources. [ChangeLog][QtQml] The qml CMake API has changed from 6.1 and is now out of Technical Preview status. The most notable change is that .qml files should no longer be specified as resources, there is dedicated handling for them in the qt6_add_qml_module(). A related change is that the qt6_target_qml_files() command has been replaced by qt6_target_qml_sources(). More complete integration with qmlcachegen, qmllint and qmldir generation is also part of the CMake API. Fixes: QTBUG-91621 Task-number: QTBUG-82598 Task-number: QTBUG-88763 Task-number: QTBUG-89274 Task-number: QTBUG-91444 Change-Id: I25aae1b0e89890394dfe2ba2824008164b2ca8d9 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Use CLASS_NAME rather than CLASSNAME for qt6_add_qml_module()Craig Scott2021-03-311-6/+11
| | | | | | | Task-number: QTBUG-88763 Change-Id: I118227ec418ac59eb6603d236b38b1a4319a51c2 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* CMake: Account for qtbase refactoring in qt_internal_add_plugin()Craig Scott2021-03-311-15/+44
| | | | | | | | | Task-number: QTBUG-88763 Pick-to: 6.1 Change-Id: I66c22f876be66ca64cd364f574a6f3e862e4abf5 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* CMake: Fix argument handling in qt_internal_add_qml_module() and friendsCraig Scott2021-03-101-113/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | If OUTPUT_DIRECTORY is set, all the QML files, as well as the qmldir and the plugin should end up in that directory. We should not confuse that with the install directory, which is separate. For qt_internal_add_qml_module(), we can provide the defaults for both OUTPUT_DIRECTORY and INSTALL_DIRECTORY. For the latter, don't support a separate INSTALL_LOCATION keyword, only use INSTALL_DIRECTORY. With these changes, qtbase no longer has to contain qml-specific logic for these paths in QtPluginHelpers.cmake. Refactor the way arguments are collected and passed through to the internal call to qt6_add_qml_module(). This simplifies the code and also exposed that QML_FILES was not being identified as an allowed argument, TYPEINFO was the wrong type of argument and DO_NOT_INSTALL was not a valid argument (or at least was ignored). The qt_internal_add_module() function was also duplicating logic that was largely already implemented by qt6_add_qml_module(). Rework things a little to remove that duplication. Task-number: QTBUG-88763 Pick-to: 6.1 Change-Id: I629ff63a9f8302c79694970f7b8e664a2b5d587b Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* CMake: Remove INSTALL_QML_FILES optionUlf Hermann2021-03-021-8/+0
| | | | | | | | | | | | QML files shall always be installed together with the module. Not installing them will just cause confusion. Pick-to: 6.1 Change-Id: I380b03f1cfce92f2c1fd1e0205e0fa307b385097 Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Maximilian Goldstein <max.goldstein@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Fix the argument removal in qt_internal_add_qml_moduleUlf Hermann2021-02-281-1/+3
| | | | | | | | We need to remove all the QML-specific arguments. Pick-to: 6.1 Change-Id: I99a1712251c5cf9cb6dfe399a2f1177d435a2af7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* CMake: Allow building pure QML modules not backed by C++ sourcesAlexandru Croitor2020-11-121-16/+18
| | | | | | | | | | | | | | | | When no C++ sources are passed to qt_internal_add_qml_plugin (a pure QML module), create a C++ backed Qt plugin anyway. In such a case, generate a dummy plugin.cpp containing a QQmlEngineExtensionPlugin subclass. The class name is autogenerated from the QML import URI. The class constructor will call the qmltyperegistrar generated void qml_register_types_foo() function, to ensure the needed module versions are registered for the QML module. Change-Id: I19959dafdf0dc837c6037e7dc1d549b7420110a7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* qmltyperegistrar: Add past-major-version optionMaximilian Goldstein2020-11-101-0/+2
| | | | | | | | Adds the option to specify past major versions of modules to be registered. This is necessary for modules that don't export any types themselves to work when built statically. Change-Id: I4b4a379f92707ec64cbb32f91db9d010440b95a2 Reviewed-by: Fawzi Mohamed <fawzi.mohamed@qt.io>
* CMake: Clean up logic to prepare building pure QML modulesUlf Hermann2020-11-061-2/+12
| | | | | | | | | | | | | | Make sure we don't create bogus typeinfo entries, do create a target if there are no C++ files, and do install created targets. This way we do build the qmlcachegen-created files and link them into a library which is subsequently deployed. It's not a real plugin, though, and we need to specially handle this in QML. That's material for a separate change. Change-Id: I516d4611b6041a23489ce57df38dd83114dcc5de Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* CMake: Use qt_internal_add_plugin in qt_internal_add_qml_moduleAlexandru Croitor2020-10-131-1/+1
| | | | | | | | | The implementation means to call qt_internal_add_plugin because that's the one that handles the 'QML_TARGET_PATH' option. Task-number: QTBUG-86827 Change-Id: I3289741458cb8038f576bc4b08617f42fce98710 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Allow optional imports in qmldir filesUlf Hermann2020-10-081-0/+2
| | | | | | | | | | This is useful for modules that select their imports at runtime using qmlRegisterModuleImport(). We can list all possible variants as optional imports so that tools can see what types might be available. Task-number: QTBUG-87130 Change-Id: I8a37bdde79aef3619fd1f05e5ea6781d521afa88 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* CMake: Allow installation of qmltypes filesUlf Hermann2020-10-081-0/+6
| | | | | | | | This is what qmake does on install_qmltypes and we do want to install the qmltypes files of our own modules. Change-Id: Iad430aab87f21331abf332ca5c92f9d7edc47bb0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Rename internal functions to contain qt_internalAlexandru Croitor2020-09-251-4/+10
| | | | | | | | | Offer compatibility wrapper functions until we update all of the Qt repos to use the new names. Task-number: QTBUG-86815 Change-Id: I834ac1d5d6549bd4e33b9916a2198a7a03c0d183 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-25 09:14:16 +0000