Re: [meta-qt5] Problems with Qt5 and CMake

[Stefan Herbrechtsmeier <stefan@herbrechtsmeier.net>]

Am 24.05.2013 14:07, schrieb Martin Jansa:
> On Fri, May 24, 2013 at 01:34:40PM +0200, Manuel Nickschas wrote:
>> 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.
> I don't have any component which uses CMake and Qt5, so I haven't tested
> this, but .prl, .la and .pc files were also generated with wrong paths,
> check those patches in qtbase.
Pkg-config use /PKG_CONFIG_SYSROOT_DIR to modify the include and library 
paths and the files are manual fixed to only contain the path on the 
machine./

> It would be good to let CMake respect OE_QMAKE_PATH_* variables, so you can
> generate .cmake files with correct paths for target and in OE builds
> override them with OE_QMAKE_PATH_* values to use correct sysroot.
CMake offers find_xxx functions and CMAKE_FIND_ROOT_PATH to modify the 
program, include and library paths.
Or you could use CMAKE_CURRENT_LIST_DIR in a cmake file to get the path 
of the file.

The problem is that its up to the developer to use this functions and 
that CMake don't support a common way to model the dependencies like the 
Requires field of pkg-config files.

> The same for finding native host tools in
> OE_QMAKE_PATH_EXTERNAL_HOST_BINS.
The cmake.class overlays the machine sysroot over the native sysroot and 
don't install any binaries into the machine sysroot. Thereby the 
find_program function detects the binary in the native sysroot and all 
the other find_xxx functions detect the include files and libraries in 
the machine sysroot.