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-qt-kde-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1380680528.25780.72.ca...@schumann.anu.edu.au
