The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
When a ROS agnostic system library, like pcl, opencv, console_bridge, orocos_kdl, or fcl are listed in the rosdistro file, it means that for one of several possible reasons we are packaging that library manually. Those reasons might include:
We recommend that developers use the upstream debians when ever possible, but sometimes there is a need to roll our own.
As for the finding of these system libraries. We highly encourage developers to use the mechanism provided by the upstream library for finding and using it, e.g. cmake's Module's and Config files, pkg-config, or something similar. In the past we used to wrap up the discovery of these packages in our own infrastructure for convenience, though this is not the policy any longer, there still are some people doing it the old way.
If you see someone doing:
find_package(catkin REQUIRED COMPONENTS some_system_package)
Open an issue against them. This is not correct. You can see the recommendation here:
http://www.ros.org/reps/rep-0136.html
In your question you give this as an example:
find_package(libuvc REQUIRED)
This is only incorrect if someone is adding a Findlibuvc.cmake as a patch to the ros-<rosdistro>-libuvc packaging. If they are shipping a Findlibuvc.cmake with their own package which internally locates and exposes libuvc then that is fine. Also if libuvc's upstream provides a Findlibuvc.cmake or libuvc-config.cmake file then this is also ok.
If there are PPA's which contain these libraries, then we should have them imported into our debian repository (we do this for pcl and openni and a handle full of others). We cannot use the normal "add a PPA" method because our dependency resolution tool rosdep doesn't handle PPA's currently. Otherwise a ROS debian built against the PPA for fcl, for example, then users without that PPA would not be able to install it.
In the long run we would like to be able to correctly support PPA's, but it will require top to bottom integration.
P.S.
There is also the scenario where we need to repackage debians that exist in PPA's. For example, pcl-1.7 has debians in their PPA, but because of the way they are packaged, they depend on either a deb called libopenni or openni depending on the Ubuntu version. ROS package's also depend on openni, but we only use one of those. So for one of three supported Ubuntu's we had to repackage the pcl-1.7 debs to use the correct openni debian. See:
https://github.com/ros/rosdistro/issues/1895
| | 2 | No.2 Revision |
When a ROS agnostic system library, like pcl, opencv, console_bridge, orocos_kdl, or fcl are listed in the rosdistro file, it means that for one of several possible reasons we are packaging that library manually. Those reasons might include:
We recommend that developers use the upstream debians when ever possible, but sometimes there is a need to roll our own.
As for the finding of these system libraries. We highly encourage developers to use the mechanism provided by the upstream library for finding and using it, e.g. cmake's Module's and Config files, pkg-config, or something similar. In the past we used to wrap up the discovery of these packages in our own infrastructure for convenience, though this is not the policy any longer, there still are some people doing it the old way.
If you see someone doing:
find_package(catkin REQUIRED COMPONENTS some_system_package)
Open an issue against them. This is not correct. You can see the recommendation here:
http://www.ros.org/reps/rep-0136.html
In your question you give this as an example:
find_package(libuvc REQUIRED)
This is only incorrect if someone is adding a Findlibuvc.cmake as a patch to the ros-<rosdistro>-libuvc packaging. If they are shipping a Findlibuvc.cmake with their own package which internally locates and exposes libuvc then that is fine. Also if libuvc's upstream provides a Findlibuvc.cmake or libuvc-config.cmake file then this is also ok.
If there are PPA's which contain these libraries, then we should have them imported into our debian repository (we do this for pcl and openni and a handle full of others). We cannot use the normal "add a PPA" method because our dependency resolution tool rosdep doesn't handle PPA's currently. Otherwise a ROS debian built against the PPA for fcl, for example, then users without that PPA would not be able to install it.
In the long run we would like to be able to correctly support PPA's, but it will require top to bottom integration.
P.S.
There is also the scenario where we need to repackage debians that exist in PPA's. For example, pcl-1.7 has debians in their PPA, but because of the way they are packaged, they depend on either a deb called libopenni or openni depending on the Ubuntu version. ROS package's also depend on openni, but we only use one of those. So for one of three supported Ubuntu's we had to repackage the pcl-1.7 debs to use the correct openni debian. See:
https://github.com/ros/rosdistro/issues/1895
P.S.S.
If a library like fcl does not provide a fcl-config.cmake, and cmake does not provide a Findfcl.cmake, then it is recommended to implement a Findfcl.cmake in the cmake_modules ROS package, so that other packages can reuse your cmake abstraction. See:
https://github.com/ros/cmake_modules/blob/master/CONTRIBUTING.md
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.