Hi Marcel, > My first question is when should I link against the backing target and when against the plugin target? In the documentation it sounds like that linking against the plugin target is the right choice, but then do I also need to manually list Q_IMPORT_QML_PLUGIN in my executable's main.cpp?
Does your plugin contain anything "interesting", or is it auto-generated by qt_add_qml_module? If you haven't created the plugin manually/extended the plugin target, then you should directly (any only) link against the backing target. At least in an ideal world. Currently, you might run into https://bugreports.qt.io/browse/QTBUG-95149 (which also can happen with static libraries, depending on your linker). Linking against the plugin in addition would fix this, but you can also apply the workaround described in https://doc.qt.io/qt-6/qqmlengineextensionplugin.html, see the section starting with "The linker might erroneously remove the generated". > My other question is related to the qt6_import_qml_plugins CMake function. I thought this function would be able to scan the QML code and automatically link against the plugin targets, but for me this never works with our own QML modules. Is this function limited to Qt's own plugins? In static Qt builds we also need to manually link against Qt6::QuickControls2, which sounds like the backing target, which confuses me even more ^^ That should actually work\u2122, are you using a recent version of CMake and are you using qt_add_executable for the final binary? Kind regards, Fabian Kosmale _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
