cmake.bbclass questions

cmake.bbclass questions

[Matt Madison]

[-- Attachment #1: Type: text/plain, Size: 1388 bytes --]

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.

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.

I don't know that much about CMake, so if anyone has any advice, I'd
appreciate it.

Thanks,
-Matt

[-- Attachment #2: Type: text/html, Size: 1518 bytes --]

Re: cmake.bbclass questions

[Stefan Herbrechtsmeier]

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

Re: cmake.bbclass questions

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

> 
> > 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}")

Great, thanks, I'll suggest that to them.

Regards,
-Matt

Re: cmake.bbclass questions

[Stefan Herbrechtsmeier]

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