catkin and rosdep

[Jack O'Quin]

I am confused about the relationship (if any) between catkin and rosdep.

* Does catkin resolve *all* dependencies using CMake `find_package()`?
- Both system libraries and other "wet" ROS components?
- "Wet" packages cannot depend on "dry" packages, right?

* Who uses rosdep?
- users building from source?
- build farm?
- "dry" ROS packages?
- packaging system?

* How do I display all the direct and indirect dependencies of a package?
--
joq

[Tully Foote]

On Fri, Aug 3, 2012 at 2:46 PM, Jack O'Quin <jack....@gmail.com> wrote:

I am confused about the relationship (if any) between catkin and rosdep.

 * Does catkin resolve *all* dependencies using CMake `find_package()`?
    - Both system libraries and other "wet" ROS components?
    - "Wet" packages cannot depend on "dry" packages, right?

Both these are correct.  You use standard cmake find_package to find either system libraries or catkinized packages.  

The only thing that catkin does for you is allow you to work in your build space and override the system installation simply by adding the package to the catkin workspace.  This works the same way as adding a package to your ROS_PACKAGE_PATH.  

There are hacky ways to make "wet" packages depend on "dry" packages, they involve manually writing find rules for the dry stacks and adding them into your cmake module search path.  We definitely don't recommend it, and won't package that way.  

 * Who uses rosdep?
   - users building from source?
   - build farm?
   - "dry" ROS packages?
   - packaging system?

Rosdep is used at the packaging level to allow the user or build farm to make sure that all the dependencies are installed.  The dependencies are declared at the level of installation units.  However they are not used by cmake/catkin at configure/compile time.  

 

 * How do I display all the direct and indirect dependencies of a package?

In the current design rosstack or the equivalent will continue to work.  

 

--
 joq

--
You received this message because you are subscribed to the Google Groups "ROS Buildsystem Special Interest Group" group.
To post to this group, send email to ros-sig-b...@googlegroups.com.
To unsubscribe from this group, send email to ros-sig-buildsy...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Tully Foote
tfo...@willowgarage.com
(650) 475-2827

[Jack O'Quin]

On Mon, Aug 6, 2012 at 4:14 AM, Tully Foote <tfo...@willowgarage.com> wrote:
>
> On Fri, Aug 3, 2012 at 2:46 PM, Jack O'Quin <jack....@gmail.com> wrote:
>>
>> I am confused about the relationship (if any) between catkin and rosdep.
>>
>> * Does catkin resolve *all* dependencies using CMake `find_package()`?
>> - Both system libraries and other "wet" ROS components?
>> - "Wet" packages cannot depend on "dry" packages, right?
>
> Both these are correct. You use standard cmake find_package to find either
> system libraries or catkinized packages.

That's what I thought (and hoped). Thanks.

> The only thing that catkin does for you is allow you to work in your build
> space and override the system installation simply by adding the package to
> the catkin workspace. This works the same way as adding a package to your
> ROS_PACKAGE_PATH.

So, $CMAKE_MODULE_PATH basically replaces $ROS_PACKAGE_PATH for "wet" stacks?

I presume "dry" stacks will still have to be built separately, *after*
all the wet stacks have been installed. (Is that still true for
Groovy?)

> There are hacky ways to make "wet" packages depend on "dry" packages, they
> involve manually writing find rules for the dry stacks and adding them into
> your cmake module search path. We definitely don't recommend it, and won't
> package that way.

+1 not to recommending it. This stuff is confusing enough, already.

>> * Who uses rosdep?
>> - users building from source?
>> - build farm?
>> - "dry" ROS packages?
>> - packaging system?
>
> Rosdep is used at the packaging level to allow the user or build farm to
> make sure that all the dependencies are installed. The dependencies are
> declared at the level of installation units. However they are not used by
> cmake/catkin at configure/compile time.

Thanks. That helps me keep it straight.

I am probably not the only one struggling to get a clear picture of
how all this fits together. We could use some block diagrams, I think.
--
joq