ubuntu-phone team mailing list archive

[Dimitri John Ledkov <xnox@xxxxxxxxxx>]

On 15 December 2013 12:26, Alberto Mardegan
<alberto.mardegan@xxxxxxxxxxxxx> wrote:
> Hi Dimitri,
>
> On 12/13/2013 07:58 PM, Dimitri John Ledkov wrote:
>> As of latest cmake upload into trusty, it is now trivial to
>> cross-compile CMake based projects:
>>
>> One time setup:
>> $ mk-sbuild --target armhf trusty
>>
>> Building a package:
>> $ sbuild -A -d trusty --host armhf package*.dsc
> [...]
>> Since this is built into CMake, one can use cmake direct:
>> dpkg-architecture -aarmhf cmake ../; make
>
> I'm interested in having the same support in qmake; is someone already
> working on it?

"same" will not be possible in short-term.

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.

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.

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

The second and third points will be much harder to achieve and
properly implement upstream. It has been discussed to implement this
among the Foundations team at the last vUDS. In-practice it gains as
only some gain - cross-compiling qt, and qt components themself. All
canonical lead projects and all the SDK apps use CMake, the only
exceptions are qt source packages and components that are to go
upstream into qt.


> What do your changes do, exactly? Do I understand correctly that the
> goal is to have the build system aware of the DEB_HOST_ARCH environment
> variable so that it selects the toolchain appropriate for the target
> architecture? Or is there more to it?
>

DEB_HOST_ARCH is exactly the wrong variable to key on.

If DEB_HOST_GNU_TYPE does not equal to DEB_BUILD_GNU_TYPE, the correct
cross-compilers, cross PkgConfig, moc, rcc, qmake (althought that
actually doesn't do anything useful) are selected. The install
locations are adjusted based on DEB_HOST_MULTIARCH, if they already
haven't been adjusted already. (no non-multiarch cross-compilation
support). And all of this is for qt5 only, bypassing calling
"qtchooser" (as in /usr/lib/$(DEB_HOST_MULTIARCH)/qt5/bin/* binaries
are used, instead of /usr/bin/*). Since qtchooser also doesn't know
about selecting DEB_BUILD_MULTIARCH located binaries _without_ a full
qt installation for the BUILD architecture present.


>> ps. if you are not using CMake, you should be switching to CMake =)
>
> Nice try ;-)
>

Are you implying there are canonical projects not using CMake yet?

-- 
Regards,

Dimitri.