From: Manuel Nickschas <manuel.nickschas@bmw-carit.de>
To: <openembedded-devel@lists.openembedded.org>
Subject: Re: [meta-qt5] Problems with Qt5 and CMake
Date: Fri, 24 May 2013 15:03:02 +0200 [thread overview]
Message-ID: <5622796.kW1BjNgdNO@luxon> (raw)
In-Reply-To: <519F60B9.1020604@herbrechtsmeier.net>
On Friday 24 May 2013 14:44:41 Stefan Herbrechtsmeier wrote:
Hi,
> > 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.
Hm, no, that is not the issue. The issue is that Qt5 uses a fairly recent
CMake feature where find_package and friends look for a *Config.cmake file
first, and then use that to set everything up. In case of Qt5, please have a
look at the files Qt5 (the qtbase package) installs into the target sysroot, in
/usr/lib/cmake/.
In particular, the issue is with
$sysroot/usr/lib/cmake/Qt5Core/Qt5CoreConfigExtras.cmake:
[...]
set_target_properties(Qt5::moc PROPERTIES
IMPORTED_LOCATION "/usr/bin/qt5/moc"
)
[...]
and similar for other host binaries such as rcc or qdbusxml2cpp (in
Qt5DBus/Qt5DBusConfigExtras.cmake).
The path specified there is clearly wrong for cross-compiling, because it
references the location in the target itself, without prepending the sysroot
prefix. Thus, it won't find moc. In particular, it needs not even find the moc
from the target sysroot, but from the native sysroot, as it's a host tool.
Unfortunately, I have no clue how the Qt5 build system ends up generating
those paths; I assume it's not using CMake and find_program, but
hardcodes the paths somewhere.
One could probably patch this away, but then you'd end up with host-
specific absolute paths inside the target, which will then break if you try to
use them for compiling something inside the target.
Or maybe indeed replace the hardcoded path by some CMake variable that
can then be set at cmake runtime to the proper sysroot; not sure if this would
work.
Cheers,
~ Sput
--
Manuel "Sput" Nickschas * Development Specialist, Team GENIVI
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
-----------------------------------------------------------------------------
next prev parent reply other threads:[~2013-05-24 13:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-24 11:34 [meta-qt5] Problems with Qt5 and CMake Manuel Nickschas
2013-05-24 12:07 ` Martin Jansa
2013-05-24 12:44 ` Stefan Herbrechtsmeier
2013-05-24 13:03 ` Manuel Nickschas [this message]
2013-05-24 14:56 ` Stefan Herbrechtsmeier
2013-06-10 14:09 ` Manuel Nickschas
2013-06-10 18:32 ` Stefan Herbrechtsmeier
2013-06-20 10:06 ` Manuel Nickschas
2013-06-20 11:12 ` Philip Craig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5622796.kW1BjNgdNO@luxon \
--to=manuel.nickschas@bmw-carit.de \
--cc=openembedded-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox