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 [email protected] 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 _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
