<machine> tag

The <machine> tag now uses the following syntax for setting environment variables on a remote machine:

<machine env-loader="path/to/env-loader.sh" />

For example:

<machine env-loader="/opt/ros/fuerte/env.sh" />

The env-loader file must be an executable script that accepts variable-length arguments. After performing environment setup, the script must then execute its arguments as a command. ROS installations come with a default environment loader file.

The env-loader attribution is optional. If it is not set, it defaults to /opt/ros/<distro-name>/env.sh, where <distro-name> is the ROS distribution named defined by the rules in REP 123 [2].

The following attributes are no longer supported and will raise errors:

ros-root
ros-package-path

Also, the <env> tag is no longer supported inside of a <machine> tag and will also raise an error.

etc/ros/roscore.xml

The configuraton file for roscore is now stored in etc/ros. roslaunch obeys REP 123 [2] for locating etc/ros.

This roscore.xml configuration file is a roslaunch file that defines the nodes that are launched with roscore is run. It was previously stored in the roslaunch directory.

Package-relative executables

The following sections describe the effects on and updates to the ROS package-relative specification for the new FHS layout. They also discuss changes to Python library loading and a minor change to the ROS package manifest format.

Locating executables in catkin build directories

In order to facilitate an efficient write-compile-run development cycle, it is necessary to easily run executables that are compiled to the build directory. In particular, because tools like roslaunch and rosrun use a package-relative scheme for locating executables, this same scheme must work with build artifacts. Otherwise, the user would have to install the build artifacts, which would lengthen the development cycle.

Out-of-source build systems are more complicated as an executable may be a binary build artifact, or it can be a script with executable permission in the source tree.

An alternative would be to make allow a package to have multiple directories, such as setting the ROS_PACKAGE_PATH to point to multiple locations. This would have numerous undesireable effects, such as disabling the ability to override existing packages, and also not have backwards-compatibility with many tools.

Another alternative would be to copy the entire source tree into the build space and point the ROS_PACKAGE_PATH there. This is similar to how tools like Eclipse perform out-of-source builds. This was considered undesireable as it would lengthen the development cycle for script executables, such as Python scripts, as a build would be required each time the script was modified in order to copy it back to the build space.

env-loader optional

The env-loader attribute was made optional because the most common value encodes the name of the current ROS distribution. This would make it difficult, moving forward, to maintain the same set of launch files for different distributions. The default value will allow things to "just work" in the most common case.

Breaking compatibility with <machine> tag

The rationale for these changes is discussed in the "Backwards Compatibility" section below.