On 15 December 2013 12:26, Alberto Mardegan <alberto.marde...@canonical.com> 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. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
