- 
    Bug 
- 
    Resolution: Unresolved
- 
    P3: Somewhat important 
- 
    6.8
- 
    None
- 
        c29cae46f (dev)
The attached project has a QML module that will be used by both the app, and, eventually, integration tests (they will test the UI). The structure looks like this:
.
├── CMakeLists.txt
├── Scheduler
│   ├── CMakeLists.txt
│   ├── MainScreen.qml
│   ├── schedulerglobal.h
│   ├── task.cpp
│   └── task.h
├── SchedulerApp
│   ├── CMakeLists.txt
│   ├── fonts
│   │   └── fontello
│   │       ├── config.json
│   │       ├── fontello.ttf
│   │       └── LICENSE.txt
│   ├── main.cpp
│   └── Main.qml
└── tests
    ├── auto
    │   ├── CMakeLists.txt
    │   └── unit
    │       ├── CMakeLists.txt
    │       └── tst_models.cpp
    └── CMakeLists.txt
When running SchedulerApp on Kubuntu 22.04, I get this error:
16:36:41: Starting /home/mitch/dev/temp/scheduler-Desktop_Qt_6_6_0_GCC_64bit-Debug/SchedulerApp/schedulerapp... QML debugging is enabled. Only use this in a safe environment. QQmlApplicationEngine failed to load component qrc:/qt/qml/SchedulerApp/Main.qml:3:1: module "Scheduler" is not installed 16:36:41: /home/mitch/dev/temp/scheduler-Desktop_Qt_6_6_0_GCC_64bit-Debug/SchedulerApp/schedulerapp exited with code 255
Apparently this is because the recommended structure in this scenario is to have the Scheduler module (project) be a child of the SchedularApp, rather than have them as siblings. This is what the Wearable example does:
https://code.qt.io/cgit/qt/qtdeclarative.git/tree/examples/quickcontrols/wearable/CMakeLists.txt
Fabian mentioned that it will work if I:
- Install the Scheduler module. That's fine for deployment but it shouldn't be necessary for the development phase, in my opinion: QTBUG-122987.
- Link against the backing library of the Scheduler module, because then it should be found via the qrc path (on Linux).
However, https://doc.qt.io/qt-6/cmake-build-reusable-qml-module.html doesn't explicitly say that the "example"/"mylib" structure is the only supported structure. If this is the case, it should be clearly documented.
If it's not the only supported structure (which I argue it shouldn't be), it should also explain how to handle the case of many executables that use a QML module, as the example project structure it uses is very simplistic.
- relates to
- 
                    QTBUG-111946 How should QML modules be installed with cmake (with Qt 6.4 or later)? -         
- Reported
 
-         
- 
                    QTBUG-137199 Minimize discrepancies in QML import paths between different QML tools, out-of-the-box -         
- Reported
 
-         
- 
                    QTBUG-133377 Windeployqt does not install QtQuick.VectorImage -         
- Closed
 
-         
- 
                    QTBUG-133547 QML modules: document how they should be modernized or written for new code -         
- Closed
 
-         
- 
                    QTBUG-122987 Investigate allowing sibling projects to pick up QML modules without installation -         
- Closed
 
-         
