All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.