On Tue, 2013-10-01 at 22:59 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: ... > > 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.
In my case I'm using Gnome, so I don't have that path problem. My qtcreator would be using the standard qmake at /usr/bin/qmake. > This affects the way qtcreator detects Qt installations. ... > 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]: Agreed, it does make sense for Qt4 to be the default at the moment. > > 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. > Using qtchooser sounds like a reasonable way of detecting all known Qt versions. Gives a bit of overkill with "5" vs "qt5" vs "qt5-x86_64-linux-gnu", but I guess for developers more is better than less. Thanks for the explanation! Drew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
