[Qbs] "qbs setup-qt" and Qt built for cross-compilation

[Christian Kandeler]

On Thu, 4 Jan 2018 14:08:43 +0100
Ola Røer Thorsen <ola at silentwings.no> wrote:

> > > I'll have to build from a build server as well, and now I tried running  
> > qbs  
> > > from the command line, setting up the qt version I'm using using "qbs
> > > setup-qt". I got some warnings from it, is this a bug or can it be  
> > ignored?
> >
> > Depends. It means that qbs modules for these Qt modules are not created,
> > so you will not be able to do this in your products:
> >
> > Depends { name: "Qt.bootstrap" }
> > Depends { name: "Qt.qmldevtools" }
> >
> > The first one you should never need to do. I don't know what the
> > qmldevtools library is for.
> >
> >  
> Right. I'm not a Qt developer so I do not know either. Qbs just seems to
> expect them.

Yes, because Qt declares them to be present via the contents of mkspecs/modules. There simply seems to be an inconsistency in that installation.

> > > Seems like setup-qt is expecting to find the Qt libraries in the path
> > > relative to where qmake is installed.  
> >
> > What makes you think that? The output you quoted does not suggest it.
> > The libraries, along with their prl files, are looked up in the value
> > qmake -query gives you for
> > QT_INSTALL_LIBS (more or less, the real code takes care of some special
> > cases). The list of libraries should correspond to a subset of the files in
> > mkspecs/modules/qt_lib*.pri.
> >
> Sorry this came ut wrong. I should probably have written "qbs should rather
> expect to find them at <path_to_qmake>/../lib".

No, definitely not. The values from qmake -query are authoritative. 

> For the Qt versions normally installed by the Qt installer (Qt for x86_64)
> into <qt_path>, all these libraries are installed in <qt_path>/lib, and
> you'll find qmake in <qt_path>/bin. libQt5Bootstrap and libQt5QmlDevTools
> are found together with the rest of the Qt libraries.
> 
> When doing cross compilation however, the two mentioned libraries are still
> built for the host computer and installed in the host's lib directory,
> where all the other libraries built for the target device (here, arm imx6)
> are installed in the target sysroot qt/lib directory. This is my
> observation, I don't know why or what these are used for.

Only the ones in the sysroot are relevant for qbs when setting up the modules.

> > > The files that qbs is looking for here are not in the target rootfs, but
> > > rather in
> > >
> > > /hostqt/lib  
> >
> > These are probably for the host version of the respective library. Look
> > for the associated .a files in the same directory and check their
> > architecture. It should be x64 or whatever your host machine is.
> > I suppose the prl files in the sysroot are simply missing, for reasons I
> > don't know. Do the following files exist?
> > /targetsysroot/opt/qt/lib/libQt5QmlDevTools.a
> > /targetsysroot/opt/qt/lib/libQt5Bootstrap.a
> 
> The files are built for the host machine (x86_64) and are only installed in
> the host lib directory. We have .a, .la and .prl-files.

This makes sense.

> They do not exist in the target sysroot/opt/qt/lib.

This does not: To my knowledge, if there is a pri file in mkspecs/modules and its contents do not mark it as a non-library, then a binary and a prl file should exist in the target lib dir.
So it appears to me that this is a Qt installation problem in that either the pri file should not have been installed or the prl file should have.
There might also be some subtleties that I don't understand and this is actually intended, but that'd be strange.
Either way, I don't think the whole thing constitutes a problem for you.

> With the specific qmake binary I get when building Qt for cross
> compilation, I run
> 
> qmake myproject.pro && make
> 
> and it will use the correct compiler (the cross-compiler also used to build
> Qt), the correct Qt version and all the correct compiler flags and build my
> project for the target device.

Yes, because qmake is tied to that Qt installation.

> Doing the same with qbs requires some more work. I've got ~15 colleagues as
> well as some build servers that all need to build this project without
> really knowing much about qbs, so I'll make a script that sets up qbs
> properly for them.
> 
> Would be nice if qbs could extract also this information from the qmake
> binary that is used to identify the qt version, as the information is there
> somewhere (but very well hidden I guess). In the long run I guess qbs will
> try to avoid using qmake as an "identifier" completely?

Ideally, qbs modules would fall out of the Qt build process. Let's see.


Christian