From kde-buildsystem Thu Dec 19 18:45:51 2013 From: Dimitri John Ledkov Date: Thu, 19 Dec 2013 18:45:51 +0000 To: kde-buildsystem Subject: Re: frameworks build instructions wrong / won't work with kubuntu 14.04 Message-Id: X-MARC-Message: https://marc.info/?l=kde-buildsystem&m=138747877125050 It would have been nice to preserve CC on replies to me. I'll try to use mailing archives to reply to the thread here. Not sure if threading will be preserved, if not, please excuse me. On 18 December 2013 17:09, Harald Sitter wrote: > Alohas, > > tldr: in ubuntu 14.04 automoc will (currently does) fall over dead > with a qt5 built according to frameworks build instructions. what to > do? > tldr; actually there is no evidence that neither qt5, kde, framework5, build-instructions, or cmake, for all of the above upstream or distro-provided, are broken in any shape or form, nor require any actions from anybody. Ubuntu Trusty Tahr is an experimental distribution at this point, with high velocity core changes. E.g. only this week eglibc was upgraded from 2.17 to 2.18 and there are still plenty of changes to come (e.g. qt5.2 with its ABI break on armhf, and updates to the core gcc/glibc toolchain etc.) The bug reported on Launchpad was briefly discussed with me on irc, which i have assigned to myself. It is a distro bug, specific to how Launchpad PPA builders and Project NEON (ab)uses those to provide a co-installable stack of experimental snapshots of upstream projects, on top of experimental & volite distribution. So really this is just a daily build failure, in the continuous integration / development on top of Ubuntu. But it looks like a few people seem to be interested in some of the details behind the bug report, that Harald brought to the intention of much wider public that currently was intended to be presented to. I am working on set of changes to qt5, qmake, cmake, debhelper. I'm yet, more or less at prototyping stage, but with some things already working. I've uploaded preliminary patch, to validate it against ubuntu archive. At this point only some package builds were tried by me, and under two configurations (amd64, and cross from amd64 to armhf). An auto cross-builder hasn't been setup yet, to validate these changes on an ongoing basis, and a full archive rebuild hasn't happened yet. (it was planned to start it a while ago, but it is still waiting on eglibc2.18 fixes in trusty, once that's in, a full archive rebuild will be started). So again, none of these changes have been yet validated and QAed, nor have been tested to be backwards compatible, nor are ready to be adopted or submitted to upstreams, nor should be subject to scrutiny. None-the-less here are answers to some of the questions raised on the two kde mailing lists the original message was sent to: From Stephen Kelly: > 1) What is the problem? my cmake prototype miss-auto-detected that a request is coming to compile a .deb package, for a debian-like distributition with multiarched system-wide qt5. If you look at my distro patch in cmake, it tries hard to detect that a deb package build is in-progress and thus otherwise not-modifying things for typical cmake usage. Setting Qt5::* target variables the way I did, is a gross temporary hack. Ideally, none of that should be needed in CMake side. > 2) Why does the package creation result in broken cmake files generated from the Qt tarball? The package creation does not result in broken cmake files generated from the Qt tarball. It's just there is no clean way to override some of the chosen (hardcoded at Qt buildtime) paths, instead of at buildtime against multiple, possibly partial, stacks of Qts. Ideally, I want to be able to use qtchooser for all Qt tools, which I can trivially instruct which Qt tool-binaries to use via environment variable overrides. But alas, I don't have patches to achieve that just yet (to the qtchooser and/or cmake file generator). I'm glad that Stephen Kelly was able to see through Harald's responses, which indeed did not provide any reasoning for the changes whats-so-ever, nor indicate that those are temporary/transient variable assignment. Indeed there are no reasons to override Qt5::* variables, and indeed shouldn't be. > This claim makes no sense. In a Qt cross compile build, the tooling is built for the host. That is correct. It's just I'm attempting to not use a Qt cross compile build, at all. Muahaha =) hence I do ask for me to finish with my prototype and complete set of changes to implement out-of-the-box multiarch cross-compilation support. At the moment, i'm still validating early prototypes, and I have a bootstrap loop to break, hence the CMake distro patch upload in the state that it was. From Sune Vuorela: >Why does it select the e.g. arm moc executable for crosscompiling on x86 to arm, rather than find paths for a cross moc file. Upon cross-compilation on x86 to arm, it selects an x86 moc executable, as provided by multiarched-qt5-on-ubuntu. After you raised this question on IRC, I was looking hard to see where it's doing it the wrong way around, but I don't see it. Do I need to explain any variables used? e.g. see the comments at the top of the MultiArchCross.cmake establishing the terms/variable pattern used. BTW, there is no cross moc file available. I am also not sure yet, if a cross-moc is required or whether a native moc binary can be re-used. It's one of the open questions that I still have, and need to investigate the actual code generator / code generated. >But I guess it is up to the ubuntu people to try figure out how they want to break stuff :/ quite it's an in-distro bug, in the in-distro changes that are specific to the in-distro packaged qt, and are carefully guarded to not affected !in-distro intended usage. Environment in the Harald's builds did manage to bypass all the safety nets and fail it's builds, under some conditions. As I pasted the build log on the bug report, the build failure is not reproducible when invoking ./debian/rules build direct without dpkg-buildpackage. So I was very clueless why Harald brought up that failing to build from source in his PPA build to a such a wide audience, when it was entirely unwarranted. And also in such a hasty manner, minutes after filing the bug in the distribution without allowing any time for a fix to be written or uploaded. > And why does it try to guess paths to rcc and moc, rather than ask qmake? I don't have a cross qmake available which knows the correct cross-locations of utils. The default locations are also compiled into qmake, and hard to change at runtime. There is some qtconfig facilities, but I still didn't manage qmake to complete override the locations at runtime, to those that I need. I'm glad there was a way for me to override those locations in cmake and for me to use cmake in my prototype. I'm still working on a solution with pure qmake, without cmake. My question is, why does the generator & qmake not simply use qtchooser? Or how to override compiled in qmake constants at runtime? Qt upstream should switch to CMake by default really.... instead of qmake/qbs stuff =) CMake is so much more flexible in non-trivial setups. > And why doesn't it also do the same with uic? Not all Qt tools have paths generated/computed to them by the Automoc feature. So I've only supplied those, to match / override the generator. But there are others that are missing in the CMake generator. E.g. qtdoc. This is with qt 5.0, I haven't tested 5.2 or trunk yet. Ideally one should have access to all qt binaries as variables in CMake, for consistency sake and to avoid people writing manual detectors / modules in CMake. I hope i've answered all emails sent to the list I'm not subscribed to. Please CC me on any replies, and feel free to email any further questions about this toolchain prototype. You can also find me on IRC, nickname xnox on a few opensourcy networks/channels. -- Regards, Dimitri. _______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem