[libcamera-devel] [PATCH] package metadata

Mon Aug 15 15:24:59 CEST 2022

Hi Christian,

On Sat, Aug 13, 2022 at 10:59:40PM +0200, Christian Rauch via libcamera-devel wrote:
> Hi Laurent,
> 
> I can understand (and was kind of expecting) that you do not want to add
> that file.
> 
> While those build systems (catkin, colcon) can be used independently of
> ROS, they are not used widely outside of ROS at the moment. I intend to
> package "libcamera" and use it in a camera node. For this, I have to
> provide the package.xml. If this is not merged upstream, I will have to
> patch the file in. This is why I was hoping that the file could be
> merged, and I do not have to manually patch the file for every release.

Do those tools expect that all projects will merge a package.xml file ?
I'm a bit surprised, thinking again about other similar systems (from
Buildroot, OpenEmbedded or Debian), they usually either maintain the
package build "instructions" (for lack of a better term) separately
unconditionally (Buildroot or OpenEmbedded) or support maintaining it
separately as a first class use case (Debian). Is there no such
ecosystem for ROS for instance ?

> Regarding bitrot... The solution is to just run a colcon build job. This
> is simplified with actions on GitHub:
> https://github.com/christianrauch/libcamera-ci/blob/ci/.github/workflows/colcon.yml.
> If you have a custom build server somewhere, I could add a CI job for
> colcon there.
> 
> If bitrot is the only concern, then I am offering to maintain the
> package.xml and its build job, in return for not having to manually
> patch that file :-)
> 
> Am 13.08.22 um 18:30 schrieb Laurent Pinchart:
> > On Sat, Aug 13, 2022 at 12:40:36AM +0200, Christian Rauch via libcamera-devel wrote:
> >> Am 12.08.22 um 00:34 schrieb Laurent Pinchart:
> >>> On Thu, Aug 11, 2022 at 09:52:30PM +0200, Christian Rauch via libcamera-devel wrote:
> >>>> This metadata file provides information, amongst others, about the version,
> >>>> licence, maintainers and build dependencies. This file is used by build
> >>>> systems (catkin, colcon) to manage a dependency graph and resolve those
> >>>> dependencies automatically.
> >>>>
> >>>> The file structure is defined at: https://www.ros.org/reps/rep-0149.html
> >>>>
> >>>> Signed-off-by: Christian Rauch <Rauch.Christian at gmx.de>
> >>>> ---
> >>>>  package.xml | 32 ++++++++++++++++++++++++++++++++
> >>>>  1 file changed, 32 insertions(+)
> >>>>  create mode 100644 package.xml
> >>>>
> >>>> diff --git a/package.xml b/package.xml
> >>>> new file mode 100644
> >>>> index 00000000..8b06f507
> >>>> --- /dev/null
> >>>> +++ b/package.xml
> >>>> @@ -0,0 +1,32 @@
> >>>> +<?xml version="1.0"?>
> >>>> +<?xml-model href="http://download.ros.org/schema/package_format3.xsd" schematypens="http://www.w3.org/2001/XMLSchema"?>
> >>>> +<package format="3">
> >>>> +  <name>libcamera</name>
> >>>> +
> >>>> +  <version>0.0.0</version>
> >>>> +
> >>>> +  <description>An open source camera stack and framework for Linux, Android, and ChromeOS</description>
> >>>> +
> >>>> +  <maintainer email="libcamera-devel at lists.libcamera.org">libcamera project</maintainer>
> >>>> +
> >>>> +  <license>LGPL-2.1</license>
> >>>> +
> >>>> +  <url>https://libcamera.org</url>
> >>>> +
> >>>> +  <buildtool_depend>python3-meson-pip</buildtool_depend>
> >>>> +  <buildtool_depend>ninja-build</buildtool_depend>
> >>>> +
> >>>> +  <build_depend>python3-yaml</build_depend>
> >>>> +  <build_depend>python3-ply</build_depend>
> >>>> +  <build_depend>python3-jinja2</build_depend>
> >>>> +
> >>>> +  <depend>libgnutls28-dev</depend>
> >>>> +  <depend>openssl</depend>
> >>>
> >>> openssl is a build dependency. Since a few days ago, it can also
> >>> optionally be a runtime dependency to replace gnutls.
> >>>
> >>>> +  <depend>boost</depend>
> >>>
> >>> We don't depend on boost anymore.
> >>>
> >>>> +  <depend>libudev-dev</depend>
> >>>> +  <depend>libunwind-dev</depend>
> >>>
> >>> These two dependencies are optional. I'm curious, how are optional
> >>> dependencies supposed to be handled ? package.xml seems specific to ROS,
> >>> does it need to pick a set of options that will be enabled in the
> >>> context of ROS, and then list the corresponding dependencies here ? If
> >>> so, how would libcamera be built on ROS, how are the meson configuration
> >>> option set ?
> >>
> >> There is no way to define or handle optional dependencies. The
> >> "package.xml" does not interact with the options for the build system.
> >>
> >> While this kind of metadata definition originates from ROS, it can be
> >> used in conjunction with colcon and rosdep to build plain CMake or meson
> >> packages without any dependencies on ROS packages. "colcon" is a kind of
> >> meta build system to build large sets of packages with cross source
> >> dependencies, and "rosdep" is a tool to install binary dependencies via
> >> distribution packages.
> >>
> >> Running "colcon build" will run with the default configuration. You can
> >> pass meson specific options via "--meson-args". However, there is no way
> >> to let the "package.xml" and "rosdep" know which of those dependencies
> >> are optional and depending on some build options. I am not sure if there
> >> is a way to specify package-specific build options inside the package.
> >> However, since libcamera defines most features as auto, you could simply
> >> add those optional dependencies to the metadata and let libcamera
> >> activate that feature automatically.
> >
> > This sounds to me like package.xml is then similar to OpenEmbedded .bb
> > recipes, or to the Buildroot package .mk files. I'm not very
> > enthousiastic about carrying in the libcamera repository package
> > descriptions for lots of different build systems, they don't really seem
> > to belong to libcamera. They're also bound to bitrot as we won't test
> > them.
> >
> >>>> +
> >>>> +  <export>
> >>>> +    <build_type>meson</build_type>
> >>>> +  </export>
> >>>> +</package>

-- 
Regards,

Laurent Pinchart