Ask Your Question
3

Build Architecture Question

asked 2011-02-14 13:12:01 -0500

William gravatar image

So I have been working on using IRI's segway library to implement a segway driver for ROS, and I have run into a situation where I don't know how to proceed.

IRI is setting up a port of their stuff for ROS, so at this point it is more educational for me.

So, the IRI segway library relies on some of their other libraries.

Here is the dependency Structure:

  • My ROS Node depends on iri_segway_rmp200.
  • iri_segway_rmp200 depends on iricomms and iriutils.
  • iricomms depends on iriutils.

All of the IRI stuff is in SVN and is LGPL licensed, my stuff can be considered MIT. They are setup to build dynamically linked libraries (.so on linux and .dylib on osx).

The way I see it there are a few ways to approach this setup in ROS: (Maybe there is a 4th, correct setup)

  1. Put a script in rosdep.yaml to (svn co; make; sudo make install) each of the libraries from IRI.
    • This is good because the libraries are installed and no further configuration is required, but requires root access
    • Also, they install Find<lib>.cmake files in the cmake shared Modules folder, which is nice
  2. Create a ROS pkg for each library and use rosmake to build them, using the svn_checkout.mk make script and patches to build and install them to the pkg dir
    • This is nice because the libraries are contained in the ros pkg
    • But, you need to export cpp flags to include and link directories
    • How do you handle runtime dynamic linking?
  3. Download/Distribute and build the libraries in your ROS pkg and statically link your node to the libraries
    • Doesn't allow multiple nodes to link to a single source for the libraries (build the libs for each node that uses them)

So here are my questions:

  1. What is the preferred method of build architecture?
  2. How do you handle dynamic linking at runtime? (the .so file is in package A, and how does a binary in package B find it at runtime?)
  3. How can you handle installing and referencing Find<lib>.cmake files that libraries have? (use manifext.xml's <depend ...=""/> instead, is my guess)
  4. What if any licensing concerns are there? (patches and static linking, etc)

Sorry if some of these questions are silly, I am still learning these more complicated build systems (rosmake/cmake).

Thanks in advanced!

edit retag flag offensive close merge delete

3 Answers

Sort by ยป oldest newest most voted
4

answered 2011-02-14 13:48:01 -0500

tfoote gravatar image

Currently your option #2 is basically the recommended technique. The manifest provides a way to export the compile and linking flags.

Ken recently put together a Tutorial about Wrapping External Libraries It's a new tutorial and any feedback on clarity etc is always welcomed.

In our review of the build system targeted for E Turtle we are shooting for a solution more like option #1 but that's in progress still.

To answer your specific questions:

  1. Option 2
  2. You can use rpath to set the linking search directories. (See the Tutorial and examples linked from within)
  3. We don't have a good solution right now. There are several ways this could be done using exports but we haven't used Find modules yet.
  4. Linking to LGPL code requires changes to the LGPL'd code to be released but not works which are linked against the libraries. For example glibc is under the LGPL license.
edit flag offensive delete link more
2

answered 2011-04-18 00:58:40 -0500

IRI Robotics Lab gravatar image

updated 2011-04-18 00:59:29 -0500

We at IRI we are working in putting all the non-ROS stuff (for segway this concerns only iriutils and iricomm) in a debian-like repository, so dependencies between packages can be handled automatically and libs are installed in standard paths.

This is a 4th way that we think will help us.

edit flag offensive delete link more
2

answered 2011-03-03 17:47:19 -0500

Daniel Stonier gravatar image

Wrapping external libraries by Makefile currently causes some problems. Ros's build system is via CMake, not Makefiles, so instructions by Makefile miss out on being able to extract information necessary for building. Some of the more important ones:

  • toolchain
  • debug mode
  • compile flags
  • link flags
  • ...

The biggie being the toolchain information - this will cause an external wrapper by makefile to just fall over dead when cross-compiling.

It's much better to put these kind of build rules/functions/targets in your CMakeLists.txt (some eros packages have some examples) where you can conveniently pick up any global configuration settings (e.g. toolchain, debug mode, compile and link flags) from rostoolchain.cmake and rosconfig.cmake. This makes sure that your ros tree and your external library are compiled with the same (or at least similar) settings. Unfortunately, this does mean learning how the cmake scripting language works and I realise most people are more comfortable with Makefiles.

Hopefully this problem will get resolved with the up and coming rosbuild2.

edit flag offensive delete link more

Comments

Spot on, thanks.
Straszheim gravatar imageStraszheim ( 2011-03-13 15:12:39 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2011-02-14 13:12:01 -0500

Seen: 833 times

Last updated: Apr 18 '11