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

[Christian Gagneraud]

[cc qt-creator, from qbs mailing list]

On 2 October 2017 at 15:39, Christian Gagneraud <chgans at gmail.com> wrote:
> 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):

Actually, only when the project is loaded for the first time, what i
refer to below as 'configure-time'

> 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...

which means that ${CROSS_COMPILE}g++ resolves to a g++ binary in an
uncontrolled environment (Qtc+qmake integration).

I think Boot2Qt/Yocto got it sorted, but haven't figured it out, i
haven't build BootToQt for a while.
The last time was with TI/beagle for fun and on an evalation license,
second time on an open source license, and now i'm dealing with
very-custom ARM toolchains/roots, so no Yocto involved.

I think that yocto is still using the old method (setup-env sourcing),
Boot2Qt hasn't merged it's solution yet.

My situation is very similar, no surprise: I have to patch qt.conf,
qmake.conf, ...

>
> 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!

At 'configure time' only, build time is another story...

>
> 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++"

Actually, several variants of "CROSS_COMPILE=arm-linux-g++"

But relative path don't work here with qmake at QtC build time. It
makes QtC/qmake happy at 'configure-kit' time only.
So with a relative path in CROSS_COMPILE, i cannot build because the
relative path at QtC build time somehow doesn't point to the right
place while it did at 'configure-kit' time. Current directory issue?
It's like the compiler is called using a shell command which starts
with qmake's $CROSS_COMPILE, which value has been evaluated at QtC
configure time, bypassing QtC's kits.

qmake's $CROSS_COMPILE is unreliable because it depends on qmake
understandings of the "world".
I don't care and i don't want that.

Can't i control $CROSS_COMPILE with QtC kits only? Or do i need to
keep QtC *and* qmake happy, and then my build system?
Does QtC depends on qmake when it comes to Qt, from a developer/user POV?

Basically is qmake's CROSS_COMPILE injected into QtC at some point or not?

Qtc relies on qmake's idea of CROSS_COMPILE at configure time, but Qtc
ignores it at build time, what can go wrong?

Why do i even need to have an explicit CROSS_COMPILE in
"devices/stuff/me-g++" qmake's mkspec? (unrelated to QtC)

And why should I even have to deal with CROSS_COMPILE in QtC, we're
using "toolchain/bsp + Qt + Device = kit", independently of build
systems, don't we?

So many stupid questions, sorry...
It reminds me 15 years ago:
make ARCH=$arch CROSS_COMPILE=/path/to/$host-$target/bin/

Chris

>
> This whole problem seems to be out of Qbs, nonetheless I think Qbs
> should output a better diagnostic message in that case.
>
>
> Thanks,
>
> Chris