[Development] androiddeployqt - how it works or should work?
Eskil Abrahamsen Blomfeldt
eskil.abrahamsen-blomfeldt at digia.com
Mon Nov 4 15:05:14 CET 2013
On 11/04/2013 02:34 PM, Felipe Crochik wrote:
> Thank you. You literally answered all my questions... but I have more ;)
> I included the "QT += network sql" to my project file and on further
> inspection of the "compile output" it seems that the way it works is
> that it will include any plugins that has all the dependencies match.
> Is that how it works "now"?
> I saw "Appending dependency from xml:....". What is this "xml" in this
> case? Is the libs.xml android\res\values the "input" or "output" of
> this process? If it is the output, what is the input?
This is just an implementation detail.
There are some libraries which are only dependencies of the plugin and
not the module, e.g. the libQtQuickParticles.so library. Since it's not
possible to make this a direct dependency of your application by editing
the QT variable, it's added to an XML file which lists it as an extra
dependency of QtQuick, so that if you do QT += quick in your .pro file,
then that library will be bundled on Android as a dependency as well,
and the particles plugin will be resolved as supported by androiddeployqt.
> I am sure that it is already in the plans (or if not for some good
> reason) but just in case: it would be very helpful if we could have
> the "androiddeployqt" or qtcreator detect the "required dependencies"
> based on the "import statements" on the qml and automatically include
> them or at least spit a "building error". I know it can't be 100%
> effective since it probably won't be able to detect "exactly" what qml
> files are being used and you can also have some embedded code stored
> as strings used to create components on the fly that probably would be
> very hard to find/parse but it would cover the "most common cases".
As I mentioned, this is the plan, yes :) We have the qmlimportscanner
now, which can be used to find which imports are actually used by your
application. The plan is to use that to find out which imports are
required. The dependencies of these can then be included automatically.
There are bigger fish to fry at the moment, though, so I don't know
exactly when we'll have time to implement this optimization.
For regular plugins (like image formats etc.) however, we cannot do
this, since it's impossible to detect which plugins will be used. So for
plugins, we'll keep the current mechanism of detecting them based on
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development