ubuntu-phone team mailing list archive

[Thomas Voß <thomas.voss@xxxxxxxxxxxxx>]

On Mon, Dec 16, 2013 at 3:06 PM, Alberto Mardegan
<alberto.mardegan@xxxxxxxxxxxxx> wrote:
> 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 think the policy and guideline is pretty simple: For every new
project that Canonical is upstream for, we will default to CMake
(language/runtime-specific build systems aside). With that, all
developers benefit from cross-build support and best possible
integration with the overall system, thereby easing local testing on
devices and in the emulator.

Do we share Online Accounts with other parties? If not, I would say
it's a very strong candidate for porting over to CMake :)

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

Appreciated, but we (as in Canonical again) work hard to consolidate
and focus our efforts around test and build infrastructure. For that,
we default to CMake. While there certainly will be exceptions we
should try hard to establish a common basis here.

Cheers,

  Thomas
>
> Ciao,
>   Alberto
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp