ubuntu-phone team mailing list archive

[Olivier Tilloy <olivier.tilloy@xxxxxxxxxxxxx>]

On Mon, Dec 16, 2013 at 12:56 PM, Dimitri John Ledkov <xnox@xxxxxxxxxx>wrote:

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

There are, yes. Off the top of my head:
 - ubuntu-ui-toolkit
 - oxide (not in the archive yet)

There might be more.