Linking relationships to plugins are incorrectly specified

Qt plugins are defined as MODULE libraries for shared library builds. A MODULE library is the correct CMake library type for representing a plugin, since it is expected to be loaded dynamically at runtime rather than linked to directly. Looking at the CMakeLists.txt files that define most plugins, they seem to use PUBLIC_LIBRARIES rather than LIBRARIES to list the libraries they link to. This is the wrong abstraction, since nothing should be linking to the plugin and hence nothing should need to be PUBLIC. This is probably just the setting used by a translation script (presumably pro2cmake.py), or it may possibly be because they were incorrectly specified as public in the original .pro files. Another possibility is that some of the private/implementation plugins should actually be ordinary shared libraries instead (i.e. if anything does really need to link to them).

In the case of static Qt builds, we do link the main Qt module libraries to the plugin libraries, but this is a link-only relationship (or at least it should be). We don't want any of the transitive usage requirements because applications and module library code still don't reference anything directly from the plugin module libraries. qtbase/cmake/QtPlugins.cmake.in is responsible for taking care of this linking and for generating the C++ stubs that are needed to cause the plugins to be initialised on startup. This is done as a convenience for consuming applications so that they don't have to explicitly do this themselves for every Qt application they write.

Associated with this, the QtPlugins.cmake.in file has been forcing even builds of Qt itself to link the main Qt module libraries to the plugins for static Qt builds (there is currently no check for QT_NO_CREATE_TARGETS). When CMake exports the main module targets, it then requires the plugin targets to exist and it includes a check in the <blah>Targets.cmake file that is generated. This check fails because those plugin targets haven't been defined yet (and they can't be because they link to the main module library and therefore require it to already exist - a chicken-and-egg problem). We need to ensure that the main Qt module libraries don't link to the plugins or else CMake will force this check.

The current cyclic dependency that exists when building Qt itself is caused by QtPlugins.cmake.in not checking QT_NO_CREATE_TARGETS before linking the module library to the plugins. The cost is that any tests or examples that try to build as part of building Qt itself will still need to explicitly add (link) the plugins they need. I have an alternative strategy for dealing with that though (see QTBUG-90820).