On Mon, Dec 16, 2013 at 12:56 PM, Dimitri John Ledkov <x...@ubuntu.com>wrote:
> 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? > There are, yes. Off the top of my head: - ubuntu-ui-toolkit - oxide (not in the archive yet) There might be more.
-- 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
