[Interest] Qt 5.14 for Android - module "QtQuick" is not installed
Hi, I’ve been trying Qt 5.14 Preview for Android. I’m looking forward to make use of the new app bundle feature. The problem is that when trying to run an existing project I’m stumbling with the following problem: I OpenGLRenderer: Initialized EGL, version 1.4 D OpenGLRenderer: Swap behavior 2 W DRC: QQmlApplicationEngine failed to load component W DRC: qrc:/qml/main.qml:3 module "QtQuick.Controls" is not installed W DRC: qrc:/qml/main.qml:2 module "QtQuick.Window" is not installed W DRC: qrc:/qml/main.qml:1 module "QtQuick" is not installed I have used the new Qt Creator 4.11.0-rc1 and re-created the android templates. I have replaced all the files except AndroidManifest.xml which I have carefully reviewed the diff and adjusted accordingly. I’m not very comfortable with the inner workings of Android + Qt glue so I’m wondering if anyone has came across with this kind of problem already. A blank quick application project works but I have seen it fail too. Regards, Nuno___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Tricks to improve moc performance?
On 10/12/19 9:14 am, Adam Light wrote: When I previously analyzed the sampling data during a moc.exe run, it was clear that the vast majority of the time was spent satisfying the includes, and most of that was checking whether a concatenation of an include path and a file name are a valid file (eg. include/path1/stdio, include/path2/stdio, etc.). It seems like the compiler (cl.exe) would need to do essentially the same thing when compiling each individual file, but it's not nearly as slow as moc. If my memory serves me correctly, we found MOC drastically slower when we upgraded from Qt 4.8 to 5.x. We had quite a few directories in INCLUDEPATH, though nothing like the number you mentioned. To get acceptable performance we trimmed INCLUDEPATH to a higher level directory and started referencing instead of just . At development time we build in Visual Studio using the vcxproj generator in qmake, which won't run multiple MOC steps in paralle. If you think your MOC time is bad, imagine running them serially... We had to rewrite our build scripts to use JOM for release builds due to this. Hamish ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Tricks to improve moc performance?
On Thu, Dec 5, 2019 at 5:09 PM Adam Light wrote: > > Does anyone else have any ideas of how we could change our build to > improve moc performance when Windows decides to be "slow"? Like, for > example, is there any way to have the moc calls run with only a few moc > processes running at once but have the rest of the build done with all > threads running. I'm pretty sure that the OS slowdown has something to do > with thread contention of some sort. > > The problem with moc.exe is even worse than I first realized. Even when Windows is in the "fast" state (that is, a full rebuild takes 4-5 minutes instead of 16-18 minutes), the vast majority of the build time is spent in moc.exe. I just collected sampling data for an entire build, excluding the qmake step. So this is the entirety of jom.exe and everything it calls during the build. Windows 10, debug build of our application, VS2017. I'm not using any /j flag with jom, so it will use all available threads (16 core/32 threads). The build took 4:54. During that time, there were a total of 551 moc.exe processes that ran, and those processes took a total of 3,896 seconds of CPU time. There were also 1270 cl.exe processes which took a total of 965 seconds of CPU time. Everything else (link.exe, ui.exe, jom.exe, was minimal) compared to these two. So moc.exe was running almost 4 times as long as cl.exe. That seems crazy to me. When I previously analyzed the sampling data during a moc.exe run, it was clear that the vast majority of the time was spent satisfying the includes, and most of that was checking whether a concatenation of an include path and a file name are a valid file (eg. include/path1/stdio, include/path2/stdio, etc.). It seems like the compiler (cl.exe) would need to do essentially the same thing when compiling each individual file, but it's not nearly as slow as moc. Adam ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Tricks to improve moc performance?
On Fri, Dec 6, 2019 at 6:08 PM Thiago Macieira wrote: > On Friday, 6 December 2019 15:10:41 PST Adam Light wrote: > > > Yes: > https://github.com/qt/qtbase/blob/dev/util/includemocs/includemocs.pl > > > > Thanks. That saved a lot of time. > > > > For what it's worth, after changing all of our code to directly #include > > the moc output, the total build time dropped by around 10%. That's > helpful. > > Nice. Did you notice a size improvement in your optimised binaries too? > > On Macintosh, with Xcode 10.2, the application's executable went from 202627092 bytes to 202587956 bytes. This is a release build (-O2). So the decrease in size is small, but measurable. I haven't tested the executable sizes on Windows yet. Strangely, on Windows, this change has almost zero effect on build time. The time to run qmake has increased slightly (about 3:10 to 3:20) but the remaining build time (everything within jom.exe) only dropped by about 8 seconds (total of about 7 minutes). On Macintosh, the qmake time also increases slightly but the rest of the build is about 45 seconds faster (6:15 to 5:29). The Windows builds are release builds with VS2017. Adam ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Klocwork errors in Qt
09.12.2019, 11:00, "Massimiliano Maini" : > On Fri, 6 Dec 2019 at 19:41, Max Paperno wrote: >> On 12/4/2019 9:31 AM, Roland Hughes wrote: >>> If you think auto won't be removed as a failed experiment, how about "new"? >>> Deprecated in C++20 and slated for removal in C++23. >>> >>> https://www.modernescpp.com/index.php/no-new-new >>> Some more reading on the removal of pointers >>> >>> https://www.fluentcpp.com/2018/04/01/cpp-will-no-longer-have-pointers/ >> >> TL;DR: This was a 2018 April Fool's joke. > > Ouch. That must hurt. Well deserved. -- Regards, Konstantin ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Klocwork errors in Qt
On Fri, 6 Dec 2019 at 19:41, Max Paperno wrote: > On 12/4/2019 9:31 AM, Roland Hughes wrote: > > If you think auto won't be removed as a failed experiment, how about > "new"? Deprecated in C++20 and slated for removal in C++23. > > > > https://www.modernescpp.com/index.php/no-new-new > > Some more reading on the removal of pointers > > > > https://www.fluentcpp.com/2018/04/01/cpp-will-no-longer-have-pointers/ > > TL;DR: This was a 2018 April Fool's joke. > Ouch. That must hurt. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
