qt_add_qml_plugin( target [BACKING_TARGET backing_target] [STATIC | SHARED] [OUTPUT_DIRECTORY] [URI] [CLASS_NAME] [NO_GENERATE_PLUGIN_SOURCE] [NAMESPACE namespace] )
If versionless commands are disabled, use qt6_add_qml_plugin()
instead. It supports the same set of arguments as this command.
This command creates the plugin target associated with a QML module. It would normally be called internally by qt_add_qml_module() to create or update the plugin associated with its backing target. You should not call this function directly unless you have special circumstances that require you to create the target in a special way.
The documentation for qt_add_qml_module() describes different structural patterns for how the CMake targets associated with a QML module can be arranged. Note that
even if the QML module has no separate backing target and all functionality is implemented directly in the plugin (not the recommended arrangement), you should still call qt_add_qml_module() rather than qt_add_qml_plugin()
.
The target
specifies the name of the target to use for the QML plugin. If it does not already exist, it will be created.
BACKING_TARGET
specifies the name of the backing target that the plugin is associated with. The backing target can be the same as the plugin target
, in which case there is only the one merged
target, but this is not typically recommended (see qt_add_qml_module() for more information). BACKING_TARGET
should always be provided unless there are
special circumstances that require the plugin target to be created before the backing target. If BACKING_TARGET
is not provided, a URI
option must be given.
By default, the plugin is created with a type that is compatible with the backing target. If the backing target is a static library, the plugin will also be created as a static library. If the backing target is a shared
library, the plugin will be created as a module library. Where no backing target is provided or the plugin has no separate backing target, the plugin type can be specified with either the STATIC
or
SHARED
keywords. If the plugin type is not determined by any of the preceding conditions, a static plugin will be created if Qt was built as static libraries, or a module library plugin otherwise.
OUTPUT_DIRECTORY
specifies the directory where the plugin library will be created. It should always be the same location as the QML module's qmldir file. When
OUTPUT_DIRECTORY
is not given, it will be obtained from information stored on the BACKING_TARGET
, where available. Note that this could be different to the directory of the backing target's own
library. If an output directory cannot be obtained from the backing target, the CMAKE_CURRENT_BINARY_DIR
is used by default.
URI
declares the module identifier of the QML module this plugin is associated with. The module identifier is the (dotted URI notation) identifier for the QML module. If URI
is not given, a
BACKING_TARGET
must be provided and the backing target must have its URI recorded on it (typically by an earlier call to qt_add_qml_module()).
Each plugin should have a C++ class that registers the module with the QML engine. By default, qt_add_qml_plugin()
auto-generates the sources for this C++ class, and adds them to the target
's list
of sources. The generated plugin class satisfies the requirements of the plugin being optional (see Module Definition qmldir Files). The class name is determined as follows:
CLASS_NAME
has been given, it will be used. It must match the name used in the QML module's qmldir
file.CLASS_NAME
has not been given, but BACKING_TARGET
has, the C++ class name will be taken from details recorded on that backing target. Those details are usually recorded by an earlier call to
qt_add_qml_module(), and they will match the name used in the generated qmldir
file. This is the recommended way to provide the class name in most scenarios.
Plugin
appended.If a namespace is given with the NAMESPACE
keyword, the plugin code will be generated into a C++ namespace of this name.
Some plugins may require the plugin class to be written manually. For example, the plugin may need to perform additional initialization or register things not implemented by the default plugin class. In such cases, the
NO_GENERATE_PLUGIN_SOURCE
option can be given. You are then responsible for writing your own C++ plugin class and adding it to the target
. Note that if you need to write your own plugin class, it is
very unlikely that the plugin can be optional. This in turn means that the NO_PLUGIN_OPTIONAL
keyword should be included in the call to qt_add_qml_module() when defining the
QML module, or else the generated qmldir
file will be incorrect. Make sure your plugin class uses the same class name as determined from the logic just above.