[libcamera-devel] [PATCH] package metadata

Mon Aug 15 21:24:17 CEST 2022

Hi Laurent,

Am 15.08.22 um 15:24 schrieb Laurent Pinchart:
> 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 ?

No. It's not a requirement. Quite often, third-part libraries are
installed by CMake wrappers that have to be maintained manually. I am
just asking to add the file to the upstream repo for the convenience of
ROS users. Some projects include that file [1], some patch it in during
the release process [2].

[1] https://github.com/AprilRobotics/apriltag/blob/master/package.xml
[2] https://github.com/frankaemika/libfranka

I think it is the same for Debian packages. Some include the "debian"
folder, some leave it to the distribution to add this information.

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