[cc qt-creator, from qbs mailing list] On 2 October 2017 at 15:39, Christian Gagneraud <chg...@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 _______________________________________________ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs