Revision history [back]

Well, this is certainly one way, but it has some disadvantages: using distro packages allows to fix bugs and add API-compatible features (for instance new filters in libpointmatcher) without requiring a recompilation of the ROS package. The problem is that the reality of the research landscape is complex and that one often wants to use a lib with ROS in a project and as a standalone utility in another project. But I agree that providing only Ubuntu packages is not so nice. Fedora packages of libnabo and libpointmatcher would be very welcomed, but again this is another problem.

So I see three solutions: - Using rosdep.yaml to fetch and install the libraries in /opt/ros. - Providing a wrapper ROS package. - Using system package on Ubuntu and manual installation on other distros.

None of these solutions please me, as they all have major drawbacks.

Also, my question remains open: Is there a way to provide an "other" or "default" target in rosdep.yaml?

Well, this is certainly one way, but it has some disadvantages: using distro packages allows to fix bugs and add API-compatible features (for instance new filters in libpointmatcher) without requiring a recompilation of the ROS package. The problem is that the reality of the research landscape is complex and that one often wants to use a lib with ROS in a project and as a standalone utility in another project. But I agree that providing only Ubuntu packages is not so nice. Fedora packages of libnabo and libpointmatcher would be very welcomed, but again this is another problem.question.

So I see three solutions: - Using rosdep.yaml to fetch and install the libraries in /opt/ros. - Providing a wrapper ROS package. - Using system package on Ubuntu and manual installation on other distros.

None of these solutions please me, as they all have major drawbacks.

Also, my question remains open: Is there a way to provide an "other" or "default" target in rosdep.yaml?

Well, this is certainly one way, but it has some disadvantages: using distro packages allows to fix bugs and add API-compatible features (for instance new filters in libpointmatcher) without requiring a recompilation of the ROS package. The problem is that the reality of the research landscape is complex and that one often wants to use a lib with ROS in a project and as a standalone utility in another project. But I agree that providing only Ubuntu packages is not so nice. Fedora packages of libnabo and libpointmatcher would be very welcomed, but this is another question.

So I see three solutions: - solutions:

• Using rosdep.yaml to fetch and install the libraries in /opt/ros. - /opt/ros.
• Providing a wrapper ROS package. - package.
• Using system package on Ubuntu and manual installation on other distros.

None of these solutions please me, as they all have major drawbacks.

Also, my question remains open: Is there a way to provide an "other" or "default" target in rosdep.yaml?

Well, this is certainly one way, but it has some disadvantages: using distro packages allows to fix bugs and add API-compatible features (for instance new filters in libpointmatcher) without requiring a recompilation of the ROS package. The problem is that the reality of the research landscape is complex and that one often wants to use a lib with ROS in a project and as a standalone utility in another project. But I agree that providing only Ubuntu packages is not so nice. Fedora packages of libnabo and libpointmatcher would be very welcomed, but this is another question.

So I see three solutions:

• Using rosdep.yaml to fetch and install the libraries in /opt/ros.
• Providing a wrapper ROS package.
• Using system package on Ubuntu and manual installation on other distros.

None of these solutions please me, as they all have major drawbacks.

Also, my question remains open: Is there a way to provide an "other" or "default" target in rosdep.yaml?

Well, this is certainly one way, but it has some disadvantages: using distro packages allows to fix bugs and add API-compatible features (for instance new filters in libpointmatcher) without requiring a recompilation of the ROS package. The problem is that the reality of the research landscape is complex and that one often wants to use a lib with ROS in a project and as a standalone utility in another project. But I agree that providing only Ubuntu packages is not so nice. Fedora packages of libnabo and libpointmatcher would be very welcomed, but this is another question.

So I see three solutions:

• Using rosdep.yaml to fetch and install the libraries in /opt/ros.
• Providing a wrapper ROS package.
• Using system package on Ubuntu and manual installation on other distros.

None of these solutions please me, as they all have major drawbacks.

Also, my question remains open: Is there a way to provide an "other" or "default" target in rosdep.yaml? Also it seems that rosdep's documentation is a bit outdated, for instance there is currently nothing in /opt/ros/lib or /opt/ros/include and ROS does not seem to use these locations.

Hello!

Well, this is certainly one way, but it has some disadvantages: using distro packages allows to fix bugs and add API-compatible features (for instance new filters in libpointmatcher) without requiring a recompilation of the ROS package. The problem is that the reality of the research landscape is complex and that one often wants to use a lib with ROS in a project and as a standalone utility in another project. But I agree that providing only Ubuntu packages is not so nice. Fedora packages of libnabo and libpointmatcher would be very welcomed, but this is another question.

So I see three solutions:

• Using rosdep.yaml to fetch and install the libraries in /opt/ros./opt/ros, possibly using apt-add-repository without rosdep.yaml on Ubuntu.
• Providing a wrapper ROS package.
• Using system package on Ubuntu and manual installation on other distros.

None of these solutions please me, as they all have major drawbacks.

Also, my question remains open: Is there a way to provide an "other" or "default" target in rosdep.yaml? Also it seems that rosdep's documentation is a bit outdated, for instance there is currently nothing in /opt/ros/lib or /opt/ros/include and ROS does not seem to use these locations.