Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Proper way to deploy 3rdparty Qt Quick plugins #319
Hello! What is the recommended way to add custom Qt Quick plugins into the AppImage?
E.g. I use Kirigami, and my build script uses this trick:
It works, but requires to launch linuxdeployqt twice.
qmlimportscanner is capable of receiving multiple
Maybe linuxdeployqt should be able to accept a list of QML import paths or at least use QML2_IMPORT_PATH env variable?
No, unfortunately, it doesn't.
Passing a path as a
By default libraries that are needed to satisfy those imports are only searched in the Qt installation, qml subdirectory. You can specify additional search paths at runtime using the
linuxdeployqt, however, only passes that qml subdirectory of the Qt installation (the default location), so one cannot specify custom locations for library search. As a hack one can create a link to the custom location from inside the Qt installation, but it is inconvenient if a distribution-provided Qt is used (requires root permissions) or there are multiple versions of this library.
As a solution, linuxdeployqt could provide a flag like
Thanks @IlyaBizyaev for the explanation. Let me understand this correctly:
If a QML import needs a .so file as a dependency, then the path to the directory in which the .so file resides needs to be passed in using
What is the scenario in which you woould need to pass in an
What would we need to change to support the
Can the whole thing be made in a way that it recognizes all needed paths automatically, without the user having to pass in arguments? I mean, if the application can run on the build system prior to running
Would it be possible for you to send a PR with the requested changes?
Yeah, that's right :)
The idea is not to replace Qt files, but to use a Qt Quick library that is neither part of Qt nor part of the application.
Not exactly. Qt Quick uses the idea of import paths, which basically are paths to the root directories of package installations, kind of like Java's CLASSPATH. E.g. if I have a Qt quick module imported like this:
and located in
It can be run thanks to the
Without this definition, you get an error like this:
— which is explained by the fact that the QML module is not required at compilation, so paths don't get recorded. Qt searches for modules in their default locations, and on Linux it's ok and works for all sorts of packages.
From how I understand the code, a block like this:
will need to be added for
Yes it would, but will take me a while to build linuxdeployqt from source code.