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 |
I don't like it at all, but I believe this is what CMake's external project support is for.
Reason I don't like it is that it circumvents the package manager, takes control away from users installing your package and if done incorrectly, will pollute the system your package is installed on with potentially incompatible artefacts (ie: if you export an include path that also points to your built-from-source dependencies by accident).
| | 2 | No.2 Revision |
I don't like it at all, but I believe this is what CMake's external project support is for.for. Be sure to look at the correct version of the CMake documentation.
Reason I don't like it is that it circumvents the package manager, takes control away from users installing your package and if done incorrectly, will pollute the system your package is installed on with potentially incompatible artefacts (ie: if you export an include path that also points to your built-from-source dependencies by accident).
| | 3 | No.3 Revision |
I don't like it at all, but I believe this is what CMake's external project support is for. Be sure to look at the correct version of the CMake documentation.
Reason I don't like it is that it circumvents the package manager, takes control away from users installing your package and if done incorrectly, will pollute the system your package is installed on with potentially incompatible artefacts (ie: if you export an include path that also points to your built-from-source dependencies by accident).
| | 4 | No.4 Revision |
I don't like it at all, but I believe this is what CMake's external project support is for. Be sure to look at the correct version of the CMake documentation.
Reason I don't like it is that it circumvents the package manager, takes control away from users installing your package and if done incorrectly, will pollute the system your package is installed on with potentially incompatible artefacts (ie: if you export an include path that also points to your built-from-source dependencies by accident).
I have followed the guide here to give rosdeps knowledge of my source tree built dependencies (although I'm not really sure what part of this points to what part of the tree, I put the yaml file in the same dir as the project.xml file and I'm hoping for the best)
rosdeps resolve on the dependencies says everything is fine, but rosdeps check on the dependent projects reports that the dependent packages can not be found.
rosdep doesn't know about source dependencies and works with the pkg manager of your OS. The fact that you have the dependencies in source form available is invisible, as the pkg manager will tell rosdep that the dependencies are not installed.
It should also come as no surprise then, that an attempt to build a debian package from the dependent packages fails at the configure step with "Can not find package configuration file provided by "dependency package" with the following names" Attempts to set an environment variable pointing to the directory containig the ...-config.cmake file for the dependencies doesn't seem to propagate through to the debian/rules binary call.
This would be CMake having problems finding your dependencies. Not rosdep.
Note that in essence this is not specific to ROS necessarily: Catkin is just CMake with 'some' convenience macros (a lot of convenience, but still). I'd suggest you get a plain CMake build working with your dependencies included and then start adding Catkin-isms.
The buildfarm will run a plain Debian package build, so there's nothing special there either (apart from some non-standard destination locations).
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.
