[Solved] What's the equivalent of macdeployqt's -qmldir=... option for iOS builds?
-
For Mac OS X builds of QtQuick applications, I've gotten used to the need to point macdeployqt's -qmldir=... at a folder containing the QML else the application's imports will fail. I've also successfully built these applications for iOS (qmake to an xcodeproj, then build and deploy-to-device in xcode)... however I have no idea how the iOS build process does the equivalent of macdeployqt's QML trawl. (In both cases I bundle QML into the app bundle via QMAKE_BUNDLE_DATA).
I just recently chopped up a project which was previously a single top-level .pro into subdirectories (to factor some stuff out into a common lib for use by multiple apps). The QML remained sitting above it all, and obviously I needed to update macdeployqt's -qmldir option with an extra "../" and the Mac OSX version worked just fine.
However the iOS build is now giving me a "module "QtQuick" is not installed" at the first QML file it loads' "import QtQuick 2.2" (and then some more of the same errors for the QtQuick.Controls and QtQuick.Controls.Styles also used in the file)... and only now it occurs to me I have no idea how iOS builds "know" which QML modules to bundle support for. Presumably it has some notion of a "qmldir" location to search similarly to macdeployqt... but where is it, and how to control it?
Any pointers gratefully received, else I'll have to rebuild the monolith...
-
Hmmm...
A closer look at a good iOS app bundle from one of my simpler, everything-in-one-folder, single .pro file projects reveals it to contain a qt.conf and a qt_qml directory full of the expected module plugins (and more).
But this problem project's built iOS app doesn't seem to have been given a qt.conf or qt_qml at all, and it's not at all obvious why not. Puzzling, as the .pro files are pretty identical. The relative position of the bundled QML remains my main suspicion.
Perplexing...
-
OK figured it out (well, figured a solution out).
The "good" project was creating a qt.conf when qmake -spec macx-xcode <projectname>.pro was executed, but the bad one wasn't. This was all a bit reminiscent of this old thread http://forum.qt.io/topic/33087/qt-5-2-beta-1-ios-qtquick-1-1-and-2-0/15 so I created an imports.qml in the subdirectory referencing the imports I wanted... and all seems well again: the iOS .app bundle starts including a qt.conf and a qt_qml full of the necessary goodness.
(Well it wasn't quite that simple: my first imports.qml had a typo in it and while qmake emitted an error message, it was whizzed off the screen before I noticed it by all the spew from the immediately following xcodebuild in my build script. Took a while to figure that one out).
If qmake is doing the job of scanning for QML dependencies for iOS builds (and presumably just looking locally), it'd be nice if there was some way of giving it a pointer where to look c.f macdeployqt's -qmldir . But for now the local imports.qml method works for me.
(Hmmm I'd change the original post's title to include a [SOLVED]... except editing it no longer seems to be an option for me... edit tool is greyed out).
-
Hi,
Looks like it's either missing from the documentation or a bug...
-
@timday said in [Solved] What's the equivalent of macdeployqt's -qmldir=... option for iOS builds?:
so I created an imports.qml in the subdirectory referencing the imports I wanted... and all seems well again
100 upvotes if I had them to give. 5 years later and this imports.qml trick still solved my iOS issue. thank you!
