[Interest] Problems with qt_add_qml_module

[Ulf Hermann]

> I'm trying to create a QML extension module using CMake, and I've run 
> into some road blocks.
> I want to create a QML module including a "plugin", based on my own code 
> rather than an auto-generated plugin stub.

My first question is why? The most important part of a QML module is 
generally a backing library that contains all the meat to the module: 
Its C++-based types, its compiled QML code etc. In addition you get a 
very, very thin plugin that is only there to load the backing library. 
Except for very specific exceptions, you should always put all your code 
into the backing library and let qt_add_qml_module generate the plugin. 
Then you have the choice of either linking the library directly into 
your application at compile time or loading the plugin at run time. The 
QML engine is clever enough to avoid the plugin loading overhead if it 
detects the backing library to be already linked.

Now, the specific exceptions are run time style selection for 
QtQuick.Controls and image providers. If you are affected by those, you 
should set NO_GENERATE_PLUGIN_SOURCE, NO_PLUGIN_OPTIONAL, and explicitly 
specify PLUGIN_TARGET and CLASS_NAME. Then you can use target_sources on 
the generated plugin target to add your own implementation of the 
specified plugin class. Be aware that you need to manually reference 
some symbols from the backing library in order to prevent the linker 
from "optimizing" the dependency away.

The examples that add custom plugins, unfortunately, all add only an 
image provider, but no actual QML types. In this case you can get away 
with making the plugin the same as the backing library. Otherwise you 
shouldn't do this.

best regards,
Ulf