qt5 automoc detection is not smart enough, when system CMake is used with non-system qt5 (undeclared, toolchain-less sys-root/prefix builds)

So qt5 upstream generates automoc integration Find modules that set Qt5::moc variable. It is set based on the qt5 build time configuration. Which is not correct, since it should use the location of the system that is executing moc, not the location of the system the compilation is performed for.

Hence, the defaults were changed in CMake package as distributed for compiling packages on Ubuntu system.

Above are examples of non-distribution targetted builds (custom) and henceworth it is expected that a Toolchain file is provided with overrides of default values which are not appropriate for the sys-root style builds as demonstrated above (a toolchain file typically sets PREFIX path, paths to pkg-config .pc modules, and from now on paths to Qt5::* variables as well)

I strongly advise project-neon to use a Toolchain file, instead of relying on default fallthroughs, to guarantee that CMake uses expected (important) toolchain binaries (compilers, generators, et. al.). Setting environmental variables and relying on the default detection is fragile, as it relies on the internal implementation details instead of choosing known-in-advance non-standard binaries.

I'll look into how to make default Ubuntu toolchain modifications in CMake more resiliant to this kind of abuse.

short answer set Qt5::moc to the right path.

Please note the scope of this bug is very limited:
* when running on a debian like system
* which has multiarch enabled
* and compiling under the environment as exported by dpkg-buildpackage (or similar, e.g. debuild, or launchpad PPA builders)
* with cmake from trusty (highly experimental and volatile)
* with a non-multiarch qt

Attaching a log which shows successful build in question when invoked in Debian policy compliant way: ./debian/rules build; fakeroot ./debian/rules binary, instead of invoking with a wrapper.

In no way this is an upstream bug, but this is a purely packaging bug. The recent distro changes to cmake are intended to not cause any packaging changes, thus this is a regression. I think there are easy ways to fix this.

Any claims that this is representative of ABI/API in Trusty, are widely exaggerated. Given that at this point in time Trusty is still early in development and is undergoing highly disruptive changes (e.g. major upstream release of eglibc, new libtool, new toolchain, new gtk, new boost, shortly new qt) this is bug is no more, than a regression in a weekly automated snapshot builds.

affected builds retried, and successfully compiled.