You can also phrase your modules as C++-only static libraries and link them all together into the application. - That will depends on which C++ library your modules depends on. Not all code can be legally made static, this restriction, seem rather short sighted. Hope they change this.
-----Original Message----- From: Ulf Hermann <ulf.herm...@qt.io> Sent: September 15, 2020 2:33 AM To: Jérôme Godbout <godbo...@amotus.ca>; interestqt-project.org <interest@qt-project.org> Subject: Re: [Interest] QML/C++ interaction in Qt6 On 9/14/20 5:29 PM, Jérôme Godbout wrote: > Oh,... now that's a deal breaker... I guess I will have to stick with > the old method for a while, having 1 plugins per modules to be expose > will need some major refactor over here. I have subrepos who have a > single .pri and might expose a few modules and some modules are > partials between subrepos. I gather my .pri to build for some targets > and platforms specific subrepos might add stuff to it. You can also phrase your modules as C++-only static libraries and link them all together into the application. Mind that tools like Qt Creator or qmllint may have a hard time figuring this out and might not give you a meaningful analysis of your QML code. You will need to manually install your .qmltypes files into the import path or merge them together into a single one in the application directory. There is no "link" step for .qmltypes files (yet). > The idea seem good, but the result doesn't scale too well and ain't > flexible. Is the old way will still work into Qt 6 then? You can still manually call qmlRegisterType, but if you want qmllint and a future QML-to-C++ compiler to see your C++ types, you shouldn't. best, Ulf _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
