Mitch Curtis
2018-12-07 06:49:12 UTC
-----Original Message-----
Jeisecke via Interest
Sent: Thursday, 6 December 2018 6:12 PM
Subject: [Interest] The QtQuick deployment story
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!
It's still easy in my opinion: just let windeployqt deploy what it needs to and you're done. Although... I've been distributing my application as a portable executable and not through an installer, purely out of laziness. Are there some extra issues involving installers that make windeployqt less convenient, or is it just the final deployed size that you have an issue with?Jeisecke via Interest
Sent: Thursday, 6 December 2018 6:12 PM
Subject: [Interest] The QtQuick deployment story
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
_______________________________________________
Interest mailing list
https://lists.qt-project.org/listinfo/interest
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
_______________________________________________
Interest mailing list
https://lists.qt-project.org/listinfo/interest