ubuntu-phone team mailing list archive

[Alberto Mardegan <alberto.mardegan@xxxxxxxxxxxxx>]

On 12/16/2013 01:56 PM, Dimitri John Ledkov wrote:
> 1) Simply because qmake encodes and assumes the same "host"
> configration options as were used when qmake & qmake modules were
> created. To properly support multiarch, all qmake modules instlalation
> path will need to transition from non-multiarch, to multiarch
> locations.

I'm not expert in cross-compilation (in Nokia we were using scratchbox,
which was settings up everything for the developer), so I didn't
completely understand what you wrote. I'll try to rephrase with my
words, to double-check if I got it right:

When qmake is built (alongside with Qt), it's built for a specific build
host/target pair. In order to support cross-compilation of Qt
applications, one need to have a qmake binary which was built with the
proper build target (and of course, with the proper build host). This
means that if one intends to build his Qt application for more
architectures, one needs to be able to have several qmake binaries
installed in parallel, one for each target architecture.

So, the point 1 you write above is about installing these qmake binaries as
/usr/lib/$(DEB_HOST_MULTIARCH)/qt5/bin/qmake

Right?

> 2) After that, qmake needs to also learn to dynamically fallback from
> multi-arch location, to non-multiarch location (in case some modules
> still ship modules in the older location) as otherwise some
> configurations will fail. This might prove to be tricky since qmake
> assumes relative paths by default for everything.

Can't we assume that we'll make sure that all the Qt packages that we
need for Ubuntu development will be property installed in the multi-arch
location? Or do I miss some hidden complication here?

> 3) After that, it needs to learn to choose non-matching architecture
> locations when performing cross-compilation. (e.g. amd64 qmake should
> be able to look up modules from arm-linux-gnueabihf location and not
> have a fizzy fit about different modules and options selected, e.g.
> when doing amd64 -> armhf compilation it should be using armhf
> defaults and compile GLESv2 instead of demanding GL, and also not make
> assumptions that e.g. "build" machine is not armhf/missing GLESv2.
> something based on environment variables / qtconfig should work, or
> e.g. creating wrapper scripts to provide e.g.
> "arm-linux-gnueabihf-qmake" which calls normal host qmake, but with
> right environment / options to make it act correctly for
> cross-compilation.

I'm a bit lost here. Is this about having well-written mkspecs
configuration files for each architecture?
I would expect that if I'm on an amd64 machine and call
/usr/lib/arm-linux-gnueabihf/qt5/bin/qmake
it should read the right mkspec file for building amd64->armhf and
therefor link to the proper Qt libraries which were build for working on
armhf (with GLES)?
Note that I'm concerned about building applications only; I do
understand that for building Qt itself things might be more complicated.

> I'm looking into the 1) point, to get qt packages co-installable from
> multiple achitectures, such that one can cross-compile using CMake on
> the host machine without using chroots.

Right, so if I didn't misunderstand you, this work is about fixing any
broken mkspec and packaging Qt in Debian with multiarch support?

[...]
> Are you implying there are canonical projects not using CMake yet?

Well, in Online Accounts we are using qmake, and for some parts of the
stack (shared with Sailfish OS, Tizen and soon KDE) we are using qmake
or the autotools. I believe that switching to cmake would be welcome by
at least the KDE front, so I don't think it's impossible to happen.

I'm just personally much happier with qmake, and since Qt developers are
typically using that or QBS, I think it's worth having a look at
supporting these build systems as well (of course, it all depends on how
much effort that means). :-)

Ciao,
  Alberto