[oe] [meta-qt5] Problems with Qt5 and CMake

Philip Craig philipjcraig at gmail.com
Thu Jun 20 11:12:02 UTC 2013


On 20 June 2013 20:06, Manuel Nickschas <manuel.nickschas at 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?



More information about the Openembedded-devel mailing list