frameworks build instructions wrong / won't work with kubuntu 14.04

[Dimitri John Ledkov]

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 <sitter at kde.org> 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.