Adding libaditof Package to Ros Index

[raebelchristo-adi]

Please add the following dependency to the rosdep database.

Package name:

libaditof

Package Upstream Source:

https://github.com/analogdevicesinc/libaditof/tree/main

Purpose of using this:

This dependency serves as an SDK that provides API calls for the ADTF3175 time of flight sensors developed at ADI.

Checks

• All packages have a declared license in the package.xml
• This repository has a LICENSE file
• This package is expected to build on the submitted rosdistro

[github-actions]

Thanks for sending a pull request to ROS distro!

This is an automated tool that helps check your pull request for correctness.
This tool checks a number of attributes associated with your ROS package and generates a report that helps our reviewers merge your pull request in a timely fashion. Here are a few things to consider when sending adding or updating a package to ROS Distro.
ROS Distro includes a very helpful CONTRIBUTING.md file that we recommend reading if it is your first time submitting a package.
Please also read the ROS Distro review guidelines which summarizes this release process.

ROS Distro Considerations

• ROS Distributions are created using REP-134 Standards Track as a guide.
• Your package name should comply to REP-144 ROS Package Naming
• Your package must build for all platforms and architectures on the ROS buildfarm. See REP-2000 ROS Releases and Supported Platforms for all supported platforms for your ROS Distro.
• Your package must contain an OSI approved license. Your package.xml file must also include that license in a machine readable format. See REP-149 Package Manifest Format Three Specification for additional details.
• A publicly available, open source, repository for your ROS package.
• While not required, we recommend that you create an account for ROS Discourse and subscribe to the appropriate release topic.
• If you would like, you may join our Discord Server and ask questions in the #infra-help channel.

Package Considerations

Having your package included in a ROS Distro is a badge of quality, and we recommend that package developers strive to create packages of the highest quality. We recommend package developers review the following resources before submitting their package.

• REP-2004 Package Quality Declaration-- The ROS 2 TSC has created a quality rating system for ROS packages. These ratings should serve as a guide for package developers. We recommend package developers achieve a quality level of three or higher.
• Documentation -- it is recommended that ROS packages include an extensive README.md file, and API level documentation using the Sphinx documentation system.
• Maintainer Responsibilities -- the ROS 2 documentation includes a guide to ROS package maintainer responsibilities that summarizes your responsibilities as an open source maintainer. While we do not enforce these requirements on package maintainers they should be considered best practices.
• We recommend that your package should strive to conform to the ROS 2 Developer Guide and the ROS 2 Style Guide.

Need Help?

Please post your questions to Robotics Stack Exchange or refer to the #infra-help channel on our Discord server.

---

For changes related to yamllint:

• ✅ All new lines of YAML pass linter checks

[christophebedard]

New package checklist:

• At least one of the following must be present
  • Top level license file: https://github.com/analogdevicesinc/libaditof/blob/eb7d2b9000a8392683a3a810a9edd8d46857ca39/LICENSE
  • Per package license files:
• License is OSI-approved:
• License correctly listed in package.xmls:
• Public source repo: https://github.com/analogdevicesinc/libaditof
• Source repository contains ROS packages
• Each package meets REP-144 naming conventions

---

I noticed that you have multiple submodules in your repository. This complicates licensing and packaging.

Generally, licenses of anything distributed with your package should be listed in the package.xml. Looking at the licenses of the repos included using submodules, they cover a bit more than MIT. Also, when relying on external dependencies, you should try to use system packages (e.g., Ubuntu system packages). If they are not available through system packages, you can use vendor packages, which you may have to create yourself if they are not available. Looks like all submodules are available as Ubuntu Focal system packages:

• libzmq: https://packages.ubuntu.com/focal/libzmq3-dev (rosdep key: libzmq3-dev)
• cppzmq: I believe this is included in the libzmq3-dev Ubuntu system package in Ubuntu <24.04
• glog: https://packages.ubuntu.com/focal/libgoogle-glog-dev (rosdep key: libgoogle-glog-dev)
• libwebsockets: https://packages.ubuntu.com/focal/libwebsockets-dev (rosdep key: libwebsockets-dev)
• protobuf: https://packages.ubuntu.com/focal/libprotobuf-dev (rosdep key: protobuf-dev)

So you could list these rosdep keys as dependencies (<depend>) in your package.xml and remove the submodules. You'd need to update your CMakeLists.txt to find the system package. Then users building your package from source would have to install the system packages (e.g., using rosdep).

I found this relevant discussion on ROS Discourse (seems like it was also about an Analog Devices package!): https://discourse.ros.org/t/buildfarm-make-install-error/39231.

Also, note that ROS Noetic will be EOL in ~2 months.

[christophebedard]

Just so that this doesn't accidentally get merged.

[raebelchristo-adi]

Alright, so here's the issue. This package wasn't primarily designed for ROS. It's a generic package which was given a package.xml in order to be built as a ros package so that it worked seamlessly with our other ros packages. The development team had stated that they needed a very specific version of the given submodules, which can't be attained through rosdep.

Since we need very specific versions, we wish to keep them as submodules. However, the problem right now is licensing right? If we addressed the licenses of each submodule in our package.xml, will our package become valid? I am wondering if adding additional license tags using this (page 10) as reference, would help solving this issue. Any advice regarding licensing is welcome since I am not quite well versed in it.

[christophebedard]

I am wondering if adding additional license tags using this (page 10) as reference, would help solving this issue. Any advice regarding licensing is welcome since I am not quite well versed in it.

That REP has not been accepted/merged yet: ros-infrastructure/rep#347. The current best practice is to list all licenses and just put an XML comment next to each one saying what part the license is for, e.g., https://github.com/ros2/rosbag2/blob/9351e6a9a46b54b37b2edd31f73e90d923e754ee/liblz4_vendor/package.xml#L10-L12. You can use the file attribute with a relative path to the corresponding license file, though: https://ros.org/reps/rep-0149.html#id17.

I didn't see them before, but you should also list the licenses of the third-party dependencies in the dependencies/ directory: https://github.com/analogdevicesinc/libaditof/tree/main/dependencies

Alright, so here's the issue. This package wasn't primarily designed for ROS. It's a generic package which was given a package.xml in order to be built as a ros package so that it worked seamlessly with our other ros packages. The development team had stated that they needed a very specific version of the given submodules, which can't be attained through rosdep.

Since we need very specific versions, we wish to keep them as submodules. However, the problem right now is licensing right? If we addressed the licenses of each submodule in our package.xml, will our package become valid?

I understand your constraints. Unfortunately, it's also about potential clashes if other packages include a different version of the same dependency, as mentioned here: https://discourse.ros.org/t/buildfarm-make-install-error/39231/2. However, your package is using add_subdirectory() and not ExternalProject_Add(), so I'm not sure if it's the same situation. However, this comment seems to imply that this is not possible.

Let me get other people's input on this. I've added this to the agenda for Tuesday's ROS PMC meeting; I'll get back to you.

[christophebedard]

Thanks for your patience. We talked about this in today's ROS PMC meeting (2025-04-01).

Unfortunately, we cannot release/distribute this as-is because of the reasons I mentioned above. You would need to rely on system packages. If that's not possible, you would need to follow the REP 136 process, but it may still not be acceptable if you rely on specific versions (I'm not sure if we accept multiple vendor packages of the same third-party lib with different versions). Also, you'd have to be careful with the licenses of those third-party dependencies, especially GPL. And, again, ROS Noetic will be EOL in <2 months, so that might not be worth it.

However, we can still proceed with this PR and only add a source: entry so that your repo/package gets indexed. We just can't (later) accept a binary release. Does that work for you?

[raebelchristo-adi]

I guess that works for us. We are fine with having just source entry for now. We also just realized that we also want to add a doc entry as well. I hope that's okay with you if I update the PR right? As it is only going to be indexed for source and doc, do we still need to update the package.xml to include the licenses of submodules and dependencies folder?

We also intend to update this repository in some time to use system dependencies rather than version specific submodules, however this will cross the EOL for Noetic. We will release that version on ROS2.

[christophebedard]

We also just realized that we also want to add a doc entry as well. I hope that's okay with you if I update the PR right?

Of course, adding a doc: entry is fine.

As it is only going to be indexed for source and doc, do we still need to update the package.xml to include the licenses of submodules and dependencies folder?

It would be good to do it (or at least mention that there are third-party dependencies that have their own licenses too), but it's not required to add source: and doc: entries here.

We also intend to update this repository in some time to use system dependencies rather than version specific submodules, however this will cross the EOL for Noetic. We will release that version on ROS2.

Sounds good.

[github-actions]

For changes related to yamllint:

• ✅ All new lines of YAML pass linter checks

[raebelchristo-adi]

Updated the PR to contain the doc: entry. If everything looks good, please merge this PR. Thank you.

[christophebedard]

Now we just need to hold for the Noetic sync