[meta-qt5] Problems with Qt5 and CMake

[meta-qt5] Problems with Qt5 and CMake

[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] Problems with Qt5 and CMake

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 3679 bytes --]

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.

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.

The same for finding native host tools in
OE_QMAKE_PATH_EXTERNAL_HOST_BINS

Cheers,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

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

[Stefan Herbrechtsmeier]

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.

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

[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 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
-----------------------------------------------------------------------------

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

[Stefan Herbrechtsmeier]

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.

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

[Manuel Nickschas]

On Friday 24 May 2013 16:56:41 Stefan Herbrechtsmeier wrote:
> Am 24.05.2013 15:03, schrieb Manuel Nickschas:

Hi,

sorry for not replying sooner, I had some other tasks to do and only recently 
could look into the issue again.

> >> 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?

Well, probably it's only find_package. Not sure if there's other macros that 
make use of the *Config.cmake feature.

> >   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.

Well, they don't. I'm not sure why Qt upstream believes so much in 
hardcoded paths, maybe it's so you can manage different Qt installations on 
the same host. They do the same for qmake, of course, which also contains 
hard-coded paths.

Since I don't think we can talk upstream into changing that approach, we 
have to see how we can workaround that on our end.

> > 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.

What would be the proper way of doing this in the CMake files shipped by 
Qt5?

/usr/bin/qt5/moc is hard-coded. We could prepend that with 
${STAGING_DIR_NATIVE} maybe, which could be exported (via 
EXTRA_OECMAKE) by recipes so it's picked up by CMake, and it would 
resolve to nothing if it's not set (so the CMake file would still work outside of 
Bitbake).

I also had to add

-DCMAKE_AUTOMOC_MOC_OPTIONS='-p.'

because moc generates wrong include paths otherwise.

I'd like to see that handled by some cmake-qt5.bbclass or similar though, to 
lower the burden for developers.

> > 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.

The latter idea wouldn't work without completely rewriting Qt's CMake stuff, I 
think; the former would amount to what I suggested above?

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
-----------------------------------------------------------------------------

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

[Stefan Herbrechtsmeier]

Am 10.06.2013 16:09, schrieb Manuel Nickschas:
> On Friday 24 May 2013 16:56:41 Stefan Herbrechtsmeier wrote:
>> Am 24.05.2013 15:03, schrieb Manuel Nickschas:
>>> 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.
> What would be the proper way of doing this in the CMake files shipped by
> Qt5?
>
> /usr/bin/qt5/moc is hard-coded. We could prepend that with
> ${STAGING_DIR_NATIVE} maybe, which could be exported (via
> EXTRA_OECMAKE) by recipes so it's picked up by CMake, and it would
> resolve to nothing if it's not set (so the CMake file would still work outside of
> Bitbake).
You can try to import the executable from a file passed via -P parameter 
to cmake. I'm not sure if this works.

add_executable(Qt5::rcc IMPORTED)
set_target_properties(Qt5::rcc PROPERTIES IMPORTED_LOCATION 
"${STAGING_BINDIR_NATIVE}/rcc4")

Regards,
   Stefan

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

[Manuel Nickschas]

On Monday 10 June 2013 20:32:27 Stefan Herbrechtsmeier wrote:
> Am 10.06.2013 16:09, schrieb Manuel Nickschas:
> > On Friday 24 May 2013 16:56:41 Stefan Herbrechtsmeier wrote:
> >> All paths in the target sysroot represents the path on the target. They
> >> should be
> >> adapted via an variable or automatically detected during runtime.
> > 
> > What would be the proper way of doing this in the CMake files shipped 
by
> > Qt5?
> > 
> > /usr/bin/qt5/moc is hard-coded. We could prepend that with
> > ${STAGING_DIR_NATIVE} maybe, which could be exported (via
> > EXTRA_OECMAKE) by recipes so it's picked up by CMake, and it would
> > resolve to nothing if it's not set (so the CMake file would still work
> > outside of Bitbake).
> 
> You can try to import the executable from a file passed via -P parameter
> to cmake. I'm not sure if this works.

It does not; -P is for processing a cmake script (see -E), but you can't use it 
to prepend a normal cmake file, unfortunately. I didn't find any other option 
that would allow to do that, either.

> add_executable(Qt5::rcc IMPORTED)
> set_target_properties(Qt5::rcc PROPERTIES IMPORTED_LOCATION
> "${STAGING_BINDIR_NATIVE}/rcc4")

This gave me the idea for an ugly workaround at least; I can overwrite the 
location in my project's CMakeLists.txt after processing 
find_package(Qt5Core). Or I could check if something like qtpaths.cmake 
exists in the source dir and include that conditionally at this point.

To avoid Yocto-specific hacks ending up in the upstream repo, I think the 
best workaround for now would be to have my recipe patch the 
CMakeLists.txt to include a generated file that overwrites the locations.

But this really should be properly fixed in meta-qt5, by modifying the 
relevant *Config.cmake files in such a way that the native tools are used 
when something is built by Bitbake (e.g. by setting some variable), and the 
target tools in case someone compiles manually on the target. We 
shouldn't force developers to have to include hackish workarounds in their 
own recipes, or worse, their upstream code. With the proliferation of Qt5 in 
the embedded space, and the fact that CMake is the de-facto build system 
for Qt-based things these days, it's a problem that will come up quite often 
in the future and deserves a global solution.

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
-----------------------------------------------------------------------------

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

[Philip Craig]

On 20 June 2013 20:06, Manuel Nickschas <manuel.nickschas@bmw-carit.de> wrote:
> This gave me the idea for an ugly workaround at least; I can overwrite the
> location in my project's CMakeLists.txt after processing
> find_package(Qt5Core). Or I could check if something like qtpaths.cmake
> exists in the source dir and include that conditionally at this point.
>
> To avoid Yocto-specific hacks ending up in the upstream repo, I think the
> best workaround for now would be to have my recipe patch the
> CMakeLists.txt to include a generated file that overwrites the locations.
>
> But this really should be properly fixed in meta-qt5, by modifying the
> relevant *Config.cmake files in such a way that the native tools are used
> when something is built by Bitbake (e.g. by setting some variable), and the
> target tools in case someone compiles manually on the target. We
> shouldn't force developers to have to include hackish workarounds in their
> own recipes, or worse, their upstream code. With the proliferation of Qt5 in
> the embedded space, and the fact that CMake is the de-facto build system
> for Qt-based things these days, it's a problem that will come up quite often
> in the future and deserves a global solution.

I'm having this exact problem trying to get qt-gstreamer to build in
OpenEmbedded.

Do you have a workaround yet that would apply to qt-gstreamer too?