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

Harald Sitter sitter at kde.org
Wed Dec 18 17:09:24 UTC 2013


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?

According to Ubuntu getting cmake to pick up the correct build
binaries (outside system paths) via environment variables is not a
sane way to do it and a toolchain file should be used instead. This is
rendering the present build instructions [1] incompatible with
Ubuntu/Kubuntu 14.04 as its cmake will pick up wrong Qt5 tools (moc
etc.) and therefore fail to build anything with a Qt build created
using the existing instructions.

The related IRC discussion is further down.

Thoughts on this? What do we do about it?

[1] http://community.kde.org/Frameworks/Building

from #kubuntu-devel:
<apachelogger> bug 1262273
<ubottu> bug 1262273 in cmake (Ubuntu) "2.8.12.1-1ubuntu2 broke
automoc" [Undecided,New] https://launchpad.net/bugs/1262273
<apachelogger> agateau: ^ in case you want to subscribe as well
<xnox> apachelogger: does project neon builds it's own qt5?
<xnox> apachelogger: and is it multiarched like the stock qt5 in ubuntu?
<xnox> apachelogger: cause in my tool chain I set an explicit path to qt5::moc
<agateau> apachelogger: does the cmake package has any patch?
<xnox> apachelogger: is proejct-neon-qt5 multiarched?
<xnox> apachelogger: if it isn't you are really ought to build
project-neon-cmake, as cmake package in the distribution has been
tailor specifically to the qt5 package as shipped in ubuntu.
<apachelogger> hm
<xnox> apachelogger: i think there are variables that you can export
to make it act more like stock "cmake", i've made sure there is a
fallback, but it's rather "opt-out" kind of thing as by default i
enabled cross-compilation without modifying all sources.
<apachelogger> that's a bug
-*- apachelogger puts on his kde developer hat
<xnox> apachelogger: what is the full path to "moc" in qt5? as in not
the qtchooser one.
-*- xnox adjusts my kubuntu-developer badge
<apachelogger> when working on kde libraries I often want to have my
own qt build, this is not working properly on ubuntu :P
<apachelogger> xnox: /opt/project-neon5/bin/moc
<apachelogger> http://paste.ubuntu.com/6595065/
-*- xnox points out, that the correct interface, is to explicitely set
QT5::moc in that case, in your toolchain file used for custom/prefix
installed system libraries, as advised by CMake.
<xnox> apachelogger: you are pointing to the last resort path. in
cmake there is Qt5::moc already set to a different location.
<apachelogger> Oo
<xnox> (as in the code path before that paste)
<apachelogger> why?
-*- apachelogger fails to compute this just now xD
<xnox> apachelogger: because the one generated at qt5 package
build-time is always wrong for the cross-compile case on Debian OS.
<apachelogger> I think the solution is to fix the qt5 cmake config,
not hardcode stuff into cmake?
<xnox> apachelogger: thus, it's adjusted to the right one. Which is
also, a wild guess, if you don't happen to use stock-cmake with
stock-qt5. Both of them are failing to guess it at all times.
<xnox> i can guard my changes better, but your are exploiting
implementation details of cmake here.
<xnox> and it's sad to see that project-neon is diverging so much.
<apachelogger> it's exploiting the fact that cmake is not supposed to
hardcode stuff :P
<xnox> apachelogger: wrong. in CMake one should use a Toolchain file
for any non-standard locations. Actual modules are, last fallback, not
the first look up.
<xnox> apachelogger: if toolchain file sets all variables, none of the
Find* foo modules are loaded, nor executed.
<xnox> apachelogger: please start using multiarch qt5 packaging then.
<apachelogger> I'll put it on my todo
<xnox> cause at the moment one can co-install qt5:i386 and qt5:amd64
which doesn't look possible with project-neon at all.
<xnox> apachelogger: when you'll do that, you will find your automoc
broken, fyi ;-)
<xnox> apachelogger: what's your pkg-config? what's your location of
.pc files? this should be passed to CMake via Toolchain file!
<apachelogger> export PKG_CONFIG_PATH :=
$(NEONDIR)/lib/pkgconfig:$(NEONDIR)/lib/$(DEB_HOST_MULTIARCH)/pkgconfig:$(PKG_CONFIG_PATH)
<apachelogger> xnox: build foo is here
http://bazaar.launchpad.net/~neon/project-neon5/project-neon5-runtime/view/head:/opt/project-neon5/share/pkg-project-neon5/0/default-settings.mk
<xnox> apachelogger: cmake_defaults and all the LD_LIBRARY_PATH,
PKG_CONFIG_PATH, QT_PLUGIN_PATH, QML2_IMPORT_PATH, are ought to live
in a Toolchain file which is passed to CMake by default.
<xnox> apachelogger: anything else is fragile, and is free to be
changed by CMake both upstream and distribution.
<xnox> apachelogger: a Toolchain file is the only contract-based
interface to guarantee correct and expected compilation in CMake.
<apachelogger> xnox: you should probably raise that at
kde-buildsystem at kde.org because that is the actuall way they expect
things to be done
<xnox> apachelogger: Anybody who uses CMake and does reproducible
builds is using Toolchain files (to e.g. enforce compiler versions /
editions / pick this or that) it's pretty standard.
<xnox> apachelogger: it's not my problem at all, that project-neon
builds chooses to have non-deterministic builds.
<apachelogger> ok
<xnox> apachelogger: CMake upstream, and Qt upstream, and KDE upstream
all support deterministic builds, for a given environment.
<xnox> apachelogger: the one who picks the environment must provide a
matching toolchain file to make it deterministic.
<xnox> apachelogger: i took special care to honor and not break any
existing users of toolchain files =/
<xnox> apachelogger: this is very low priority, as it doesn't actually
affect any packages build for the distribution, by the distribution
provided sources.
<xnox> apachelogger: don't get me wrong, it's "incompatability"
between the two and all 4 parties can claim it's a bug in the other
three. (parties being: upstreams qt, cmake, kde, ubuntu)
<xnox> that's what toolchain files are for, to assert ones expectations.

HS


More information about the Kde-buildsystem mailing list