Am 11.02.2015 um 13:33 schrieb Matt Madison:
On Wed, 2015-02-11 at 11:21 +0100, Stefan Herbrechtsmeier wrote:
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.
Ah, OK. Is that the typical pattern for CMake-based packages?
Typically a find module is needed when the upstream is not built with CMake.
http://www.cmake.org/cmake/help/git-master/manual/cmake-packages.7.html#find-module-packages
http://www.cmake.org/cmake/help/git-master/manual/cmake-packages.7.html#creating-packages
The pattern avoids the installation of files into the data directory of
a foreign project.
Regards,
Stefan
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
