tag 725146 - moreinfo tag 725146 upstream thanks On Wednesday 02 October 2013 11:19:26 Drew Parsons wrote: [snip] > > But when I build and run, I get the run-time error message: > > > > qrc:/qml/main.qml:3:1: module "QtQuick.Controls" is not installed > > I've found out what the problem is. I was using the Qt5 kit that > QtCreator found automatically. But when I had a closer look, I saw it > was a local copy of Qt5.0.0beta2, not the current Debian version of > 5.1.1. That would explain why I couldn't find it. > To get access to 5.1.1, I found I had to manually add a new kit, > specifying qmake at /usr/lib/x86_64-linux-gnu/qt5/bin/qmake. > > After I did that, specifying a build with Qt 5.1.1, I can safely "import > QtQuick.Controls 1.0" into new projects. (I still have errors adding it > to an existing Qt program, I'll assume that's just normal Qt4->Qt5 > porting problem rather than a package bug) Please file a bug if you find that's not turns out to be the case :) > So I'm reporting no error in libqt5qml-quickcontrols. But is there an > error in qtcreator, that it did not detect Qt 5.1.1 automatically? I'm > reassigning this bug to qtcreator for further discussion. Well, it turns out to be a multi-layered bug. With another bug in the middle. Let's start with the "bug in the middle". If you happen to be using KDE, there is a bug (already reported and fixed upstream) that makes $PATH to be incorrect: lisandro@luna:~$ echo $PATH /usr/lib/x86_64-linux- gnu/qt4/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games The first path should not be in there. This affects the way qtcreator detects Qt installations. Now for qtcreator's detection system. It basically searches for qmake in the path and runs qmake -version lisandro@luna:~$ qmake -version QMake version 2.01a Using Qt version 4.8.6 in /usr/lib/x86_64-linux-gnu But nowadays we currently have qtchooser in the middle. In Debian qtchooser will default to Qt4 as described in [0]: SO ARE YOU GOING TO BREAK THE ARCHIVE WITH A BIG TRANSITION? No, we have done our best to avoid having to make any changes to existing Qt4 packages. Qt tools should default to Qt4 except if overriden by any method described above. This is because we needed to avoid a big and horrendous transition for packages that build against Qt4. We simply let Qt4 be the default except if manually overriden. [0] <http://perezmeyer.blogspot.com.ar/2013/08/qt-in-debian-using-qt4-andor-qt5-in.html> But we may still have a qtcreator bug here. I just removed the file that makes Qt4 the default installation and ran qmake -version. Fail. Same with qtcreator, it will not detect any installation. Maybe it should now call qtchooser -list-versions and then call qmake for each of them. I'll check with upstream and see what they say. Kinds regards, Lisandro. -- Wiki participants are, by nature, a pedantic, ornery, and unreasonable bunch. So there's a camaraderie here we seldom see outside of our professional contacts. http://www.c2.com/cgi/wiki?WhyWikiWorks Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/
Attachment:
signature.asc
Description: This is a digitally signed message part.