Re: cmake.bbclass questions

[Stefan Herbrechtsmeier <stefan@herbrechtsmeier.net>]

Am 10.02.2015 um 23:53 schrieb Matt Madison:
> I just finished some recipes for some CMake-built packages (from the 
> Kurento project).  I managed to get everything building, but I had to 
> modify how cmake.bbclass does things, and I'm wondering if there's a 
> better way to solve some of these.
>
> Each of the packages generates a pkg-config file and a CMake module 
> that are then used by other packages (later in the build) to locate 
> their dependencies.  I see that cmake.bbclass hard-codes the 
> CMAKE_MODULE_PATH setting to point to just the location in the native 
> sysroot, but target packages can't install their CMake modules there.  
> I tweaked the definition so that when building non-native packages, 
> CMAKE_MODULE_PATH points into both the target sysroot and the native 
> sysroot.  This seemed to do the trick, but wasn't sure it was the 
> correct way to solve this.
Instead of a CMake module the project should install a 
<Name>Config.cmake in its data directory and append a private module 
directory to the CMAKE_MODULE_PATH.

> The generated pkg-config files were a bit trickier - the CMakefiles 
> that generate them assume that the CMAKE_INSTALL_xxxDIR variables are 
> always relative paths, but cmake.bbclass passes in absolute paths -- 
> which, by my read of the CMake docs, is allowed.  I think in this case 
> the Kurento CMakefiles need fixing, but there were a lot of them, so 
> it was simpler to change cmake.bbclass to strip the prefix off the 
> front of those variable settings.
CMake supports relative and absolute paths for the CMAKE_INSTALL_xxxDIR 
variables but the default are relative paths.

The CMake files sould be fixed and extract the relative path from the 
full path variable:
file (RELATIVE_PATH CMAKE_INSTALL_RELATIVE_LIBDIR 
"${CMAKE_INSTALL_PREFIX}" "${CMAKE_INSTALL_FULL_LIBDIR}")

Regards,
   Stefan