On 29 September 2017 at 23:14, Christian Kandeler <[email protected]> wrote: > On Fri, 29 Sep 2017 22:53:08 +1300 > Christian Gagneraud <[email protected]> wrote: > >> On 29 September 2017 at 21:48, Christian Kandeler >> <[email protected]> wrote: >> > On Fri, 29 Sep 2017 10:45:08 +1300 >> > Christian Gagneraud <[email protected]> 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. Thanks, Chris _______________________________________________ Qbs mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/qbs
