ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
0

Project structure for packages with in-source-tree-dependencies without installing dependencies to system?

asked 2019-08-02 20:59:36 -0600

Joshua Kordani gravatar image

I have a few projects I am trying to build in such a way that debians can be created from packages in my source tree without having to first install the dependencies to the system.

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

How am I supposed to structure this project such that I can build the dependencies and dependent packages all from source without having to first install the dependencies to the system?

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted
0

answered 2019-08-03 05:25:36 -0600

gvdhoorn gravatar image

updated 2019-08-03 05:29:52 -0600

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

edit flag offensive delete link more

Comments

So as it turns out, I am working with an existing codebase that has this issue, and the existing path for building and resolving the source level dependencies works fine, I acquire all of the build artifacts I need. The problem is that when I go to build a debian package, it appears that cmake (as you say) can no longer resolve the dependencies as the package tool seems to peform it's own configure step, triggering cmake again but this time in a way where it is unable to resolve dependencies correctly.

Joshua Kordani gravatar image Joshua Kordani  ( 2019-08-03 08:25:43 -0600 )edit

the existing path for building and resolving the source level dependencies works fine, I acquire all of the build artifacts I need.

That's great. And it would have been great if you'd have been a little clearer about this in your OP.

The problem is that when I go to build a debian package,

Just to be clear: you're talking about Bloom-ing them, or handcrafting .debs out of the packages?

gvdhoorn gravatar image gvdhoorn  ( 2019-08-04 06:44:23 -0600 )edit

As I learn more about what's really going on here, my understanding grows, so this is a wip. I am trying to use bloom for this at the moment

Joshua Kordani gravatar image Joshua Kordani  ( 2019-08-04 08:42:03 -0600 )edit
0

answered 2020-11-24 15:39:46 -0600

Joshua Kordani gravatar image

As I have learned more about how this is supposed to work, the right answer is to source the install/setup.bash to provide an underlay of the project environment on top of which you overlay the dependent projects and then build, I believe.

edit flag offensive delete link more

Question Tools

2 followers

Stats

Asked: 2019-08-02 20:59:36 -0600

Seen: 120 times

Last updated: Nov 24 '20