In Qt5, each static plugin project can declare that it should be linked by default into an application, only if a certain Qt module is linked.
This is done in the qmake project by setting the PLUGIN_EXTENDS variable. An example of that is the svg icon plugin and the cmake auto tests mock3plugin
means the plugin will be linked if the application links against the QtSvg module and
means that the mock3plugin plugin will be linked if the application links either against Qtmockplugins1 or Qtmockplugins2 Qt modules.
This is handled by qt.prf here https://github.com/qt/qtbase/blob/5.15/mkspecs/features/qt.prf#L85
We tried to implement the same behavior for Qt5 cmake support, but it doesn't actually behave like that, we merely compare some property values.
What we should do is check if the final CMake target links against a specific Qt module (the one in QT_PLUGIN_EXTENDS).
This might be difficult to do because writing a genex like
will not catch transitively linked Qt modules.
This is alluded too by the comment at
Now the Qt 6 part.
pro2cmake didn't actually port qmake's PLUGIN_EXTENDS information to CMake, so we lost that information.
Which means qt6 qmake projects will regress.
And qt6 CMake projects don't handle any kind of PLUGIN_EXTENDS functionality at all.
It's difficult to gauge how important of a feature that is. I suppose some qmake projects might break. At least that's the current state.
We should at least restore the qmake behavior, which will mean creating some new API option for qt_internal_add_plugin and annotating all plugins with the lost information, so we generate correct qt_plugn_foo.pri files.
Ideally we find a way to make it work with CMake, but that's probably less critical.