Re: cmake.bbclass questions

[Stefan Herbrechtsmeier <stefan@herbrechtsmeier.net>]

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