Ulf: I don't really care about the exact name, but looking at other Qt plugins, we generally seem to use no uppercase letters in plugin names. So, maybe just lowercase whatever it currently does and call it a day.
**Ulf:**
I don't really care about the exact name, but looking at other Qt plugins, we generally seem to use no uppercase letters in plugin names. So, maybe just lowercase whatever it currently does and call it a day.
**Decision:** TBD
...
...
@@ -53,7 +54,8 @@ NOTE: `qt_internal_add_qml_module()` currently relies on being able to pre-creat
* Should we add an explicit `NO_CREATE_TARGET` option too, which must be provided if passing in an existing target for the backing target?
* Would have to think about the case where the plugin and backing target are merged.
Ulf: I'm fine with either way. The only thing out of those options that I see as strictly necessary for users is case 1. If the others are also supported, that's fine with me. There are a few related cases that may or may not interfer here, but which are rather important:
**Ulf:**
I'm fine with either way. The only thing out of those options that I see as strictly necessary for users is case 1. If the others are also supported, that's fine with me. There are a few related cases that may or may not interfer here, but which are rather important:
```cmake
# CASE 4: No plugin at all; executable needs to link or be identical to the backing target
...
...
@@ -126,7 +128,7 @@ Running `qmllint` on any of the `BasicApp` qml files will find `TimeExample` via
NOTE: May merge the discussion of the next topic into this one too.
Ulf:
**Ulf:**
* The `IMPORT_PATH` option to `qt_add_qml_module()` is actually not for run time, if I get this right. It's explicitly for qmllint and qmlcachegen(plus). However, we should strive to generate the -I options to qmllint etc automatically.
* External projects are generally expected to install their QML modules in the system QML import path, or in some predetermined location that you can just add via engine->addImportPath(). We cannot install into those locations at build time.
* The rigid structure would be there to get you started quickly without messing with import paths. We do provide all the knobs and switches to invent your own project structure if you don't like it.
...
...
@@ -163,6 +165,13 @@ Open questions:
* Do we want to document how to set up this scenario for 6.2, or should we delay doing that until we have a robust solution to the problem of preventing the linker from discarding global constructors that register our modules, etc. (affects both shared and static libraries and plugins)? Projects would still be free to try it for 6.2 if they want to handle the linker issues their own way.
* Would a lot of our problems in the previous topic go away if we said executables cannot be QML modules? Executables can link to static libraries as QML modules and not really lose any functionality. The executables would then typically just be a simple `main.qml`, added as an ordinary resource.
**Ulf:**
* I've invented static-backing-lib/shared-plugin case in order to make it possible to have modules fully contained in their plugins. I've since learned that there is a better way to do this. We can therefore drop this case.
* Multiple QML modules in a single executable. This remains a valid case.
* We could use it to cut down on the number of shared libraries we need to ship for QtQuick.Controls for example. The QML modules can contain singletons in this case. We just need to make the qmldir and qmltypes files available in the right locations. Therefore, build dir layout and conformance to import paths (see above) does matter. `qmllint` etc need to find the qmldir and qmltypes files. The fact that the binary that contains the types is elsewhere doesn't change anything about the logical location of the module.
* Optimally, a plugin for such a module would link to the combined dynamic library that contains all the modules (if it is a library and not an executable). However, restricting the case to modules without plugins for now would be fine (and not solve the qqc2 case, but I guess we can hack that somehow).
* I still don't know how a user should set up the project so that the initializers don't get discarded by the linker. Just linking the static backing targets doesn't work, does it? Object libraries are frowned upon, AFAIU. So, how would it work?
**Decisions:** TBD
## Do we want to restrict `qt_target_qml_sources()` to require that the target given to it must be a QML module?
