## page was renamed from rosdep/MappingFile {{{#!wiki caution This page is only applicable to ROS v0.11 and older. The approach shown is no longer supported in recent versions of ROS & rosdep. Please refer to [[http://docs.ros.org/independent/api/rosdep/html/contributing_rules.html|rosdep documentation - Contributing rosdep rules]] for pointers on how setup a custom rosdep source. }}} <> == Summary == The rosdep Mapping File contains the information to translate a system dependency name into a package for a package manager or bash script based on the host operating system. == Syntax == The rosdep Mapping File is a YAML dictionary. {{{ #!python block=rosdep_syntax rosdep_name: operating_system: package1 package2 operating_system2: version1: package1 version2: package1-v2 operating_system3: | echo "this is a bash script to install rosdep_name" }}} === rosdep name === <> In line 1 the string rosdep_name defines the name by which this rosdep will be referred to in the system. There can be any number of rosdep names in each file. === Operating System Tag Unversioned === If all versions of the operating system refer to the package by the same name the version can be left out and the rosdep will be resolved to that package for all versions. <> === Operating System Tag Versioned === If different native package names are required for different versions of the operating system they each must be called out individually. Note: Every version must be called out, a "default" option is not supported. <> === Bash script to replace package list === If the system dependency is not available in the package manager for the system designated. A bash script can replace the list of packages. wIt is triggered if the yaml is parsed as a multi line string. '''NOTE: these scripts cannot be used in the creation of debian packages for stacks.''' All the dependencies of a Debian package must also be Debian packages. Scripts should only be used where installation will be from source. An example script entry: <> == Examples == Below are two example rosdep dependencies. `wxpython` is a simple one while `log4cxx` is about as complicated as they come. From this snippet you can see how to define connect a single name to multiple OSes as well as individual versions of those OSes. {{{ wxpython: ubuntu: python-wxgtk2.8 arch: wxpython centos: wxPython-devel debian: python-wxgtk2.8 log4cxx: ubuntu: 9.04: liblog4cxx10-dev 8.10: | if [ ! -f /opt/ros/lib/liblog4cxx.so.10 ] ; then mkdir -p ~/ros/ros-deps cd ~/ros/ros-deps wget --tries=10 http://pr.willowgarage.com/downloads/apache-log4cxx-0.10.0-wg_patched.tar.gz tar xzf apache-log4cxx-0.10.0-wg_patched.tar.gz cd apache-log4cxx-0.10.0 ./configure --prefix=/opt/ros make sudo make install fi 8.04: | if [ ! -f /opt/ros/lib/liblog4cxx.so.10 ] ; then mkdir -p ~/ros/ros-deps cd ~/ros/ros-deps wget --tries=10 http://pr.willowgarage.com/downloads/apache-log4cxx-0.10.0-wg_patched.tar.gz tar xzf apache-log4cxx-0.10.0-wg_patched.tar.gz cd apache-log4cxx-0.10.0 ./configure --prefix=/opt/ros make sudo make install fi debian: squeeze/sid: liblog4cxx10-dev lenny: | if [ ! -f /opt/ros/lib/liblog4cxx.so.10 ] ; then mkdir -p ~/ros/ros-deps cd ~/ros/ros-deps wget --tries=10 http://pr.willowgarage.com/downloads/apache-log4cxx-0.10.0-wg_patched.tar.gz tar xzf apache-log4cxx-0.10.0-wg_patched.tar.gz cd apache-log4cxx-0.10.0 ./configure --prefix=/opt/ros make sudo make install fi fedora: log4cxx-devel arch: | if [ ! -f /usr/lib/liblog4cxx.so.10 ] ; then mkdir -p ~/ros/ros-deps cd ~/ros/ros-deps wget --tries=10 http://aur.archlinux.org/packages/log4cxx/log4cxx.tar.gz tar xzf log4cxx.tar.gz cd log4cxx makepkg sudo pacman -U log4cxx-*.pkg.tar.gz fi macports: | if [ ! -f /opt/ros/lib/liblog4cxx.so.10 ] ; then mkdir -p ~/ros/ros-deps cd ~/ros/ros-deps wget --tries=10 http://pr.willowgarage.com/downloads/apache-log4cxx-0.10.0-wg_patched.tar.gz tar xzf apache-log4cxx-0.10.0-wg_patched.tar.gz cd apache-log4cxx-0.10.0 ./configure --prefix=/opt/ros make sudo make install fi }}} == Best Practices == It is common to place shared dependencies in lower-level `rosdep.yaml` files in order to lock-in certain versions across a tree (e.g. `boost`). This strategy also helps prevent future incompatibilities.