From kde-core-devel Wed Dec 18 17:09:24 2013 From: Harald Sitter Date: Wed, 18 Dec 2013 17:09:24 +0000 To: kde-core-devel Subject: frameworks build instructions wrong / won't work with kubuntu 14.04 Message-Id: X-MARC-Message: https://marc.info/?l=kde-core-devel&m=138738660630416 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: bug 1262273 bug 1262273 in cmake (Ubuntu) "2.8.12.1-1ubuntu2 broke automoc" [Undecided,New] https://launchpad.net/bugs/1262273 agateau: ^ in case you want to subscribe as well apachelogger: does project neon builds it's own qt5? apachelogger: and is it multiarched like the stock qt5 in ubuntu? apachelogger: cause in my tool chain I set an explicit path to qt5::moc apachelogger: does the cmake package has any patch? apachelogger: is proejct-neon-qt5 multiarched? 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. hm 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. that's a bug -*- apachelogger puts on his kde developer hat apachelogger: what is the full path to "moc" in qt5? as in not the qtchooser one. -*- xnox adjusts my kubuntu-developer badge when working on kde libraries I often want to have my own qt build, this is not working properly on ubuntu :P xnox: /opt/project-neon5/bin/moc 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. apachelogger: you are pointing to the last resort path. in cmake there is Qt5::moc already set to a different location. Oo (as in the code path before that paste) why? -*- apachelogger fails to compute this just now xD apachelogger: because the one generated at qt5 package build-time is always wrong for the cross-compile case on Debian OS. I think the solution is to fix the qt5 cmake config, not hardcode stuff into cmake? 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. i can guard my changes better, but your are exploiting implementation details of cmake here. and it's sad to see that project-neon is diverging so much. it's exploiting the fact that cmake is not supposed to hardcode stuff :P 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. apachelogger: if toolchain file sets all variables, none of the Find* foo modules are loaded, nor executed. apachelogger: please start using multiarch qt5 packaging then. I'll put it on my todo cause at the moment one can co-install qt5:i386 and qt5:amd64 which doesn't look possible with project-neon at all. apachelogger: when you'll do that, you will find your automoc broken, fyi ;-) apachelogger: what's your pkg-config? what's your location of .pc files? this should be passed to CMake via Toolchain file! export PKG_CONFIG_PATH := $(NEONDIR)/lib/pkgconfig:$(NEONDIR)/lib/$(DEB_HOST_MULTIARCH)/pkgconfig:$(PKG_CONFIG_PATH) 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 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. apachelogger: anything else is fragile, and is free to be changed by CMake both upstream and distribution. apachelogger: a Toolchain file is the only contract-based interface to guarantee correct and expected compilation in CMake. xnox: you should probably raise that at kde-buildsystem@kde.org because that is the actuall way they expect things to be done 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. apachelogger: it's not my problem at all, that project-neon builds chooses to have non-deterministic builds. ok apachelogger: CMake upstream, and Qt upstream, and KDE upstream all support deterministic builds, for a given environment. apachelogger: the one who picks the environment must provide a matching toolchain file to make it deterministic. apachelogger: i took special care to honor and not break any existing users of toolchain files =/ apachelogger: this is very low priority, as it doesn't actually affect any packages build for the distribution, by the distribution provided sources. 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) that's what toolchain files are for, to assert ones expectations. HS