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

Manuel Nickschas manuel.nickschas at bmw-carit.de
Mon Jun 10 14:09:41 UTC 2013


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



More information about the Openembedded-devel mailing list