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
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
