On Fri, Jan 14, 2022 at 8:09 AM Ulf Hermann <ulf.herm...@qt.io> wrote:
> If you want the QML engine to find your module, you need to follow > certain conventions around the paths. > My resistance to this is the self-containment of the given project/target. I don't mind following the convention(s) for the paths inside the resource file, this is perfectly fine. I'm taking an issue with supposing a specific build directory structure is all. I don't even mind enforcing some convention for the source directory, as this is something I can control easily myself. > You can create a separate CMake target just for your QML module if you > like that better. Then you don't have to mess with the existing target's > output path. > I don't want to mess with the output path at all. What I want is to have some library that encapsulates the QML module (possibly with additional C++ code), which library I link directly already. I believe this is a perfectly reasonable use case, I'm not attempting something very exotic, am I? You should _not_ manually call the type registration. This is private > API and it _will_ break. > Okay, noted, I'm not going to do it. No. You can store a pointer to the type registration function somewhere > in order to prevent the linker from dropping the dependency. > > I recommend the "custom directory layouts" section of > https://www.qt.io/blog/qml-modules-in-qt-6.2 Thank you! I'd found your blog post but I must've skimmed through the important content instead of taking the time I suppose. I will read it more carefully this time and try to follow it.
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
