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
## Discussion about the behavior of target creation by default
...
...
@@ -51,6 +53,18 @@ 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:
```cmake
# CASE 4: No plugin at all; executable needs to link or be identical to the backing target
qt_add_qml_module(Foo NO_CREATE_PLUGIN_TARGET)
```
```cmake
# CASE 5: Plugin target same as backing target; that is, the whole module lives in the plugin
## Should we rename NO_GENERATE_SOURCE to NO_GENERATE_PLUGIN_SOURCE in qt_add_qml_plugin()?
...
...
@@ -112,6 +126,23 @@ 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:
* 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.
* Being able to quickly set up a basic project is important. In Qt5, you rarely had to use import paths because you rarely created proper QML modules. So, this part is new to our users. If you cannot get anything started without setting import paths then people will perceive it as broken.
* The case of loading the starting point from the resource file system is important, but separate. Currently you do have to set up an import path for this, and you do have to link all the modules together, and all the plugins need to be optional. That's quite a few extra requirements.
* We might merge those cases and add the extra requirements to the rigid structure. I'm actually not opposed to this, but it should be an explicit step.
* The argument about linting a file from `TimeExample` is important. We still need an import path in the build directory even if we load the starting point from the resource file system by default. For finding the root of the import path a few things have been proposed:
1. Remove TARGET_PATH from the end of CMAKE_CURRENT_BINARY_DIR. If it doesn't match, warn. Otherwise that's the import path. The upside of this is that it's very simple. The downside is that it dictates a project structure where all the modules are in the same import path (unless externally provided)
2. Mark some directories as import path with some CMake construct. Warn if URIs of QML modules below them don't match the target paths. This has the upside of being precise and extensible, but the downside of requiring a manual setting. I don't know if it actually works. We might just automatically mark any directory that contains an executable as that is potentially an application binary dir. If so, we need a way to override it.
3. The tools themselves could automatically deduce the import path like the build system would in option 1. This has the upside of requiring no change to the build system and the downside of adding overhead and complexity to the tools. It also might produce false positives for cases where you invent your own project structure.
* Whatever way we choose for finding the import path, we still have the problem of placing the `BasicApp` module in a suitable directory. The following aspects need to be considered:
1. Typically, the module contained in an executable won't be used by any other module (which you can override, though). Therefore, it does not need to reside in the import path or follow any rules about URI and TARGET_PATH.
2. If we derive the import path from the module location, the `BasicApp` module needs to be in a subdirectory `BasicApp`, so that we can compute the import path from its location. That requires us to ditch the concept of building modules into CMAKE_CURRENT_BINARY_DIR ... Or we make special rules for such "starting point" modules.
3. If we determine the import path independently of the module location, we can build modules into CMAKE_CURRENT_BINARY_DIR without further special casing.
* We need to be able to import the other modules with minimal effort at run time. In the best case this means not setting any explicit import path. This _seems_ to be related to the location of `BasicApp` but is actually _not_. It's a function of the locations of the executable and the other modules, and of whether we load from the host file system or the resource file system.
**Decisions:** TBD
## What's our expectation on linking to a backing library without a plugin, and ensure that it works?
