[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#725146: qtcreator does not automatically find Qt5.1.1



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


Reply to: