Re: [meta-qt5] Qt5 and CMake in OE/Yocto

[Otavio Salvador <otavio@ossystems.com.br>]

On Fri, May 24, 2013 at 7:04 AM, Manuel Nickschas <
manuel.nickschas@bmw-carit.de> wrote:

> we're trying to deploy a Qt5-based piece of software on a Yocto system (I
> hope this is on topic for this mailing list as well; the issue I'm about to
> describe should occur on pure OE too). As build system for this software,
> we
> use CMake.
>
> We've added meta-qt5 (master) and successfully installed qtbase on the
> platform. However, there is a serious issue if one tries to cross-compile
> CMake-based software against the resulting Qt5 installation.
>

\m/ nice!


> As you probably know, Qt5 ships its own support for CMake in the form of a
> bunch of Qt5$ModuleConfig.cmake files somewhere in /usr/lib/cmake.
> These files are found with a find_package(Qt5Core) call and set everything
> needed for building against the Qt5 installation. The problem is, that
> those
> files contain absolute paths to both the libraries and the host tools for
> building (such as moc, rcc etc).
>
> meta-qt5 actually installs two sets of CMake files for Qt5, one in the
> target
> sysroot (from the qtbase package) and one in the native sysroot (from the
> qtbase-native package). A recipe inheriting cmake.bbclass will find the
> ones
> in the target sysroot.
>
> The issue is that these files hardcode the paths *on the target*, i.e.
> they try
> to find the host tools in /usr/bin/qt5/ and the libraries in /usr/lib/.
> Obviously,
> this fails when trying to build against those, because the target sysroot
> path
> isn't prepended.
>
> If I remove the CMake files from the target sysroot (could not figure out
> how
> to force it otherwise in my recipe), the ones from the native sysroot are
> found
> and used instead. These actually contain proper paths into the native
> sysroot, so the build tools - like moc - are found and the program compiles
> successfully - but it can't link, because it then tries to link to the
> libraries in
> the native sysroot. And those are, of course, built for the wrong
> architecture.
>
> I'm at a loss as of how to properly fix this issue. What we need is a set
> of
> CMake config files for Qt5 that point to the tools in the native sysroot
> and the
> libraries in the target sysroot. However, we probably wouldn't want to
> deploy
> them as such on the target (because there we want to actually point to both
> tools and libraries in /usr for the target), and we probably also wouldn't
> want
> to do it in the native sysroot (because then we couldn't build native
> things
> that like to link to the native libraries).
>
> Of course, I could just copy the CMake files from Qt5, patch them
> accordingly and ship them as part of my project; but bundling such things
> is
> evil and I would really like to avoid this.
>
> So now I'm wondering, are people here aware of that issue and have a plan
> or idea on how to fix this?
>
> https://bugreports.qt-project.org/browse/QTBUG-28922 might be relevant,
> although I am not sure if this is describing a similar issue and if it
> applies to
> the multiple sysroot approach Yocto uses.
>

Martin has been the main drive force in the Qt5 work but he seems to focus
in qmake projects. I didn't yet start moving to Qt5 (I use CMake a lot) so
didn't look at the issue yet.

The best way to fix it seems to change the CMake modules (in Qt5) to use
the environment variables to grasp the need paths. This way, we can reuse
the qmake_base class and get it properly set I think.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750