Openembedded Devel Discussions
 help / color / mirror / Atom feed
From: Stefan Herbrechtsmeier <stefan@herbrechtsmeier.net>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [meta-qt5] Problems with Qt5 and CMake
Date: Fri, 24 May 2013 16:56:41 +0200	[thread overview]
Message-ID: <519F7FA9.60100@herbrechtsmeier.net> (raw)
In-Reply-To: <5622796.kW1BjNgdNO@luxon>

Am 24.05.2013 15:03, schrieb Manuel Nickschas:
> 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
What do you mean by 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/.
I don't use qt but have similar problems with other cmake projects.

> 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).
If they would use find_program they would get the correct path for moc.

> 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.
All paths in the target sysroot represents the path on the target. They 
should be
adapted via an variable or automatically detected during runtime.

> 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.
You should prepend a variable or use find_program.



  reply	other threads:[~2013-05-24 14:56 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
2013-05-24 14:56       ` Stefan Herbrechtsmeier [this message]
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=519F7FA9.60100@herbrechtsmeier.net \
    --to=stefan@herbrechtsmeier.net \
    --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