Ruby Library Packages

On the C++ side, we have already discussed the separation between the bulk of the implementation in C++ libraries and their framework integration in components.

The same should be applied on the Ruby side of the system. A lot of the functionality needed to e.g. look at diagnostics data streams from the components can be made framework-independent (i.e. Syskit independent). It is somehow weaker in the Ruby case though, as in the end most of the data processing is done in C++ in a Rock system.

For code meant to be executed within Syskit, generally speaking, do not do too many things within the Syskit process. Syskit is in charge of coordinating the system's components, and having long computations within the Syskit process will increase Syskit's reaction times.

Creating and Adding Packages to the Workspace

This is covered in the Workspace and Packages section

Executive Summary: You need to first pick a category and a name the workspace conventions for information about how to name your library package.

The Ruby packages are expected to follow the de-factor standard Ruby package layout set forth by RubyGems. The best way to create a new ruby package is to use bundle gem and add Rock's manifest.xml to it.

When using VSCode, the package will not be picked up by the vscode-rock extension until it is part of the main manifest. Adding the package path to the layout section of autoproj/manifest is enough at this stage. You will however have to define the package in the autobuild and source.yml files before you push the updated manifest to your team members. For instance, when creating tools/timeseries one would do

bundle gem tools/timeseries
<create tools/timeseries/manifest.xml>

and then add

  - ...
  - tools/timeseries

autoproj runs rake within the package during the build, which means that it runs the Rakefile's default task.

Integrating 3rd-party libraries

External gems can be installed by autoproj using the osdeps mechanism. For now, autoproj does not know how to look at a package's gemspec (which defines the gem's dependencies), so you will have to duplicate dependencies between the gemspec and the manifest.xml.

You may also install them in the workspace if you plan to work on them. You would however have to declare their path manually within autoproj/Gemfile to make sure the checked out repository is used:

gem 'timeseries', path: File.expand_path(File.join('..', 'tools', 'timeseries'), __dir__)

Package Dependencies

It is common for packages to depend on other packages.

When adding a dependency to a Ruby package, you must add it to the package's manifest.xml file. If you do mean to distribute your Ruby package as a RubyGem, you will also have to modify the bundler-generated gemspec file.


Testing is now an integral part of modern development process, and Rock provides support to integrate unit testing in the development workflow.

Ruby packages are expected to provide a test target in their Rakefile to run the tests. The Rakefile generated by bundle gem has one.

Rock's preferred test framework is minitest and mocking framework is flexmock.

Type System Plugins

In order to smooth the interface between the Rock type system and the Ruby layers, one can provide a typelib_plugin.rb file within a Ruby package. Just put the file under your package's main directory (e.g. lib/mypackage/typelib_plugin.rb) to have it automatically loaded.

Let's go now to the Rock specific part of functionality integration, components