[Interest] The QtQuick deployment story

Nils Jeisecke nils.jeisecke at saltation.com
Thu Dec 6 18:12:13 CET 2018


Hi list,

A long standing source of irritation is the deployment strategy for
QtQuick based applications, especially on Windows.

On macOS most people probably don't care what ends up in that
application bundle but on Windows you have to provide an installer. In
the good old days there were some DLLs and a single EXE file to
consider. That was easy!

Nowadays helpers like windeployqt distribute hundreds of .qml, .qmlc, .js
and .jsc files and a bunch of of plugin DLLs into many subdirectories
(Qt, QtGraphicalEffects, QtQml, QtQuick (containing most of the QtQuick
modules), QtQuick.2 (containing the QtQuick engine plugin).

At least with 5.12.0 some of those modules seem to continue working just
fine when removing all the .qml and .qmlc files (but don't touch the
qmldir files!). I've checked this for "Controls.2" and "Dialogs". Some
legacy modules ("QtQuick.Controls 1") don't like this.

I guess this is because both the .qml and .qmlc files are embedded
as Qt resources in the non-deprecated modules.

Is this assumption correct?
Can you run into problems when not distributing the .qml/.qml/.js/.jsc files?
Could the current behavior of windeployqt (and Co.) be regarded as a bug?
Is the deployment documentation somewhat lacking?
Does this list of questions sound like a song of the Talking Heads?

Thanks for reading

Nils


More information about the Interest mailing list