So Yocto Pyro 2.3.1 cross-compilation SDK, Qt 5.9+QML app, cmake and QtQuickCompiler all walk into the build environment...
-
Hello.
I am working on a project in which we build an Qt+QML application through cmake on following platforms:
- x86-64 Windows (test, prebuilt commercial Qt installation),
- x86-64 Linux (test, prebuilt commercial Qt installation),
- ARM Cortex-A9 Linux (target platform, during compilation Qt is used as a part of Yocto Pyro 2.3.1 cross-compilation SDK).
I have configured the cmake files to optionally use QtQuickCompiler as described here: http://doc.qt.io/QtQuickCompiler/qquickcompiler-building-with-cmake.html
This approach works on pre-compiled commercial SDKs used in [1] and [2], but does not work on [3]. We build our own cross-compilation SDK and system image for ARM platform using yocto. It compiles Qt from source. I've changed switch in Yocto SDK configure step of Qt to "-commercial" and placed the license file as ".qt-license" in /home/<user>/ on Linux machine used to build both OS and SDK.QtQuickCompiler is not built. It is not built from source even on PC, which makes sense: if it is meant to be available as a tool being a part of commercial package, releasing source code of it in any form would be bad idea.
So. Because QtQuickCompiler converts QML to C++, I assume that during build process of [3] I should be able to use the same tool which is used in [2], correct? A simple copy of "qtquickcompiler" binary from [2] SDK to a folder in which qmake used in [3] is placed (<sdk folder>/sysroots/x86_64-pokysdk-linux/usr/bin/qt5/) does not work - cmake does not find the compiler and proceeds to build the application without it.
Is using the QtQuickCompiler possible in [3]? How to make it work?
-
Qt 5.9 comes with QML cache which offers similar performance (for subsequent app runs) to the compiler http://blog.qt.io/blog/2017/05/31/performance-improvements-with-qt-5-9-lts/ and it is already built into the app.
The blog post suggests that Qt Company have run the Qt Quick Compiler for ARM CPUs - I suggest you get in touch with them about it.
-
I've looked into "precaching" right at the beggining of my optimization quest. This documentation entry suggests enabling it by adding few lines to the *.pro file. And here is the problem: we do not use the *.pro file in our build process. "FIND_PACKAGE( Qt5 5.6 REQUIRED Core Qml Quick )", "FIND_PACKAGE(Qt5QuickCompiler QUIET)" and explicit call to Qt's RCC are the only things in our CMakeLists that are related to Qt - where the second one fails to find the compiler during cross-compilation.
In other words: I'm more interested in solutions that can be easily included in our build chain than in solutions that do work, but require major changes in our approach.
-
I've looked into "precaching" right at the beggining of my optimization quest. This documentation entry suggests enabling it by adding few lines to the *.pro file. And here is the problem: we do not use the *.pro file in our build process. "FIND_PACKAGE( Qt5 5.6 REQUIRED Core Qml Quick )", "FIND_PACKAGE(Qt5QuickCompiler QUIET)" and explicit call to Qt's RCC are the only things in our CMakeLists that are related to Qt - where the second one fails to find the compiler during cross-compilation.
In other words: I'm more interested in solutions that can be easily included in our build chain than in solutions that do work, but require major changes in our approach.
As I see.
@NevilX said in So Yocto Pyro 2.3.1 cross-compilation SDK, Qt 5.9+QML app, cmake and QtQuickCompiler all walk into the build environment...:
This documentation entry suggests enabling it by adding few lines to the *.pro file
That's a long shot, but maybe you can do this:
- create some simple QML example app (using qmake), even the default one from Qt Creator will do
- run qmake and copy the Makefile to some safe location
- add these QML cache lines to .pro
- run qmake again
- check the resulting Makefile - what has changed? Maybe you can incorporate the same actions to cmake via a script of some sort.
-
Also: Qt5QuickCompiler has an added benefit of obfuscating the QML sources. As far as I know It is not something that caching could provide, even with prebuilt cache.
@NevilX said in So Yocto Pyro 2.3.1 cross-compilation SDK, Qt 5.9+QML app, cmake and QtQuickCompiler all walk into the build environment...:
Also: Qt5QuickCompiler has an added benefit of obstructing the QML sources. As far as I know It is not something that caching could provide, even with prebuilt cache.
Yes, that's why I suggest contacting the Qt Company. They have run the qml compiler on ARM so they should be able to help. Especially when you are - as you mention - a commercial customer.
-
@NevilX said in So Yocto Pyro 2.3.1 cross-compilation SDK, Qt 5.9+QML app, cmake and QtQuickCompiler all walk into the build environment...:
Also: Qt5QuickCompiler has an added benefit of obstructing the QML sources. As far as I know It is not something that caching could provide, even with prebuilt cache.
Yes, that's why I suggest contacting the Qt Company. They have run the qml compiler on ARM so they should be able to help. Especially when you are - as you mention - a commercial customer.
@sierdzio said in So Yocto Pyro 2.3.1 cross-compilation SDK, Qt 5.9+QML app, cmake and QtQuickCompiler all walk into the build environment...:
Yes, that's why I suggest contacting the Qt Company. They have run the qml compiler on ARM so they should be able to help. Especially when you are - as you mention - a commercial customer.
I'll try this, thanks.
