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

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

[Manuel Nickschas]

Hi,

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.

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.

Thank you for any pointers.

Cheers,
~ Sput
-- 
Manuel "Sput" Nickschas * Development Specialist, Head Unit Software
BMW Car IT GmbH * http://www.bmw-carit.de
Embedded Software House Ulm * Lise-Meitner-Str. 14 * 89081 Ulm
-----------------------------------------------------------------------------
BMW Car IT GmbH
Geschäftsführer: Harald Heinecke und Reinhard Stolle
Sitz und Registergericht: München HRB 134810
-----------------------------------------------------------------------------

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

[Otavio Salvador]

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