[Qbs] Qt.core.qtBuildVariant is not supported by this Qt installation

[Christian Kandeler]

On Mon, 2 Oct 2017 15:39:01 +1300
Christian Gagneraud <chgans at gmail.com> wrote:

> On 29 September 2017 at 23:14, Christian Kandeler
> <christian.kandeler at qt.io> wrote:
> > On Fri, 29 Sep 2017 22:53:08 +1300
> > Christian Gagneraud <chgans at gmail.com> wrote:
> >  
> >> On 29 September 2017 at 21:48, Christian Kandeler
> >> <christian.kandeler at qt.io> wrote:  
> >> > On Fri, 29 Sep 2017 10:45:08 +1300
> >> > Christian Gagneraud <chgans at gmail.com> wrote:
> >> >  
> >> >> Hi there,
> >> >>
> >> >> Using QtC 4.4 with built-in Qbs, and custom Qt/toolchain builds
> >> >> (Qt-5.6), I can use qbs to open my projects in QtC.
> >> >>
> >> >> But today I had to investigate a bug in our code which required me to
> >> >> use a different custom build (still is 5.6, but older)
> >> >>
> >> >> With this Qt build Qbs complains with:
> >> >> /home/developer/.config/QtProject/qtcreator/qbs/1.9.0/profiles/qtc_NOS_imx6_d5c4604e/modules/Qt/core/core.qbs:181:
> >> >> warning: The following properties have invalid values:
> >> >> Qt.core.availableBuildVariants: the Qt installation supports no build variants
> >> >> Qt.core.qtBuildVariant: '' is not supported by this Qt installation  
> >> >
> >> > Please show us the QT_CONFIG line(s) from that Qt's mkspecs/qconfig.pri file.  
> 
> Hi Christian,
> 
> CONFIG +=  cross_compile shared qpa no_mocdepend release qt_no_framework
> 
> QT_CONFIG +=  minimal-config small-config medium-config large-config
> full-config release_tools fontconfig evdev tslib directfb linuxfb
> c++11 accessibility egl eglfs eglfs_viv opengl opengles2 shared qpa
> reduce_exports clock-gettime clock-monotonic posix_fallocate mremap
> getaddrinfo ipv6ifname getifaddrs inotify eventfd threadsafe-cloexec
> system-jpeg system-png png system-freetype harfbuzz system-zlib nis
> iconv glib dbus dbus-linked openssl rpath gstreamer-0.10 icu
> concurrent audio-backend release
> 
> It used to work, when adding kit manually. I think that this is where
> the regression comes from: Now i'm using an online repo that creates
> the kits automatically.
> 
> Nonetheless, i am able to use these new auto-installed QtC kits:
> - create a new GUI project (qmake)
> - choose a cross-dev kit
> - setup the remote device
> - click run
> - play with the app on the target.
> 
> All of the above in debug, release or profile mode.
> 
> I'm using a specific mkspec in my kit (eg,
> /path/to/Qt/mkspecs/devices/arm-linux-g++), this mkspec sets
> "CROSS_COMPILE=arm-linux-gnueabi-", but the arm-linux-gnueabi-gcc is
> not on the PATH.
> So QtC prints some warning at start-up (and only at startup):
> Project ERROR: Compiler arm-linux-gnueabi-g++ not found. Check the
> value of CROSS_COMPILE -device-option
> Could not read qmake configuration file
> /.../mkspecs/devices/linux-arm-gnueabi-g++/qmake.conf.
> 
> But then, i can still build/run OK (since i guess QtC uses the full
> compiler path via the toolchains settings).
> 
> The old method was to setup the path *before* running QtC from the
> command line...
> 
> So after a couple of trial and error, i can confirm that this is what
> upsets qbs.
> 
> Removing CROSS_COMPILE from qmake.conf, makes qmake not happy at all.
> So for the moment, i set CROSS_COMPILE to a relative path to the
> toolchain, QtC doesn't complain, and Qbs works as before!
> 
> I think this CROSS_COMPILE is needed when running qmake from the
> command line, but it should not be needed when using QtC kits.
> I want to be able to quickly switch b/w kits, and i want the kits to
> "obey" my choice of toolchains, i don't want them to rely on some
> hard-coded absolute or relative path, or the PATH since i have to deal
> with several version of "arm-linux-g++"
> 
> This whole problem seems to be out of Qbs, nonetheless I think Qbs
> should output a better diagnostic message in that case.

Hi Christian,

I've read this message now a couple of times, but I must admit I haven't grasped how any of that relates to the original problem. All I can say is that as far as I can tell from the code we use in qbs to set up Qt modules and from your original error message, it looks to me that qbs receives the information (from Qt Creator) that QT_CONFIG contains neither "debug" nor "release", and thus the list of supported build variants is empty. If that is the case (perhaps because Creator has concluded that the Qt version is not functional), then there is not much qbs can do about it.

Christian