Getting started


How does the Orocos Toolchain work?

The toolchain is a set of libraries and programs that you must compile on your computer in order to build Orocos applications. In case you are on a Linux system, you can use the script, which does this for you.

After installation, these libraries are available:

  • orocos-rtt : The component run-time library
  • orocos-ocl-* : The standard Orocos components for setting up applications
  • typelib and utilmm : Helper libraries for the tools.

These programs are available:

  • autoproj : building and updating the toolchain
  • typegen : generates typekits from classes and structs, which tell Orocos which data you want to communicate. Orocos already knows the basic C/C++ data types, you can use this tool to 'transport' any class or struct between components.
  • orogen : create components that can be deployed either statically (through oroGen itself) or dynamically by using the deployer. Creating components using oroGen requires a very minimal knowledge of the RTT API, and is therefore suited for new users.
  • deployer : creates dynamic deployments (loads components from an XML file) + console
  • taskbrowser : console that connects to running applications
  • rttlua: alternative Lua-scriptable taskbrowser
  • cdeployer: creates dynamic deployments (without console)

Creating components

Orocos component libraries are living in packages. You need to understand the concept of packages in Orocos in order to be able to create and use components. See more about Component Packages

Your primary reading material for creating components is the Orocos Components Manual. A component is compiled into a shared library (.so or .dll).

Use the orocreate-pkg script to create a new package that contains a ready-to-compile Orocos component, which you can extend or play with. See Using orocreate-pkg for all details. (Script available from Toolchain version 2.1.1 on).

Alternatively, the oroGen tool allows you to create components with a minimum knowledge of the RTT API.

Creating applications

The DeploymentComponent loads XML files or scripts and dynamically creates, configures and starts components in a single process. See the Orocos Deployment Manual

The TaskBrowser is our primary interface with a running application. See the Orocos TaskBrowser Manual

Upgrading from RTT 1.x

Take a loot at the Upgrading from RTT 1.x to 2.0 webpage.

Ugrading from Toolchain 2.x to Toolchain 2.8.x

Tips and trics can be found at the Upgrading from Toolchain 2.x to Toolchain 2.8.x, especially for ROS integrated installations with ROSBUILD and CATKIN.

Using orocreate-pkg

Where to find it

The orocreate-pkg script is installed in your bin directory where the deployer and other OCL tools are installed, or you can find it in orocos-toolchain/ocl/scripts/pkg/orocreate-pkg. When you source, orocreate-pkg will be in your PATH.

How to use it

The script takes at least one argument: the package name. A second option specifies what to generate in the package, in our case, a component:
$ cd ~/orocos
$ orocreate-pkg myrobot component
Using templates at /home/kaltan/src/git/orocos-toolchain/ocl/scripts/pkg/templates...
Package myrobot created in directory /home/kaltan/src/git/orocos-toolchain/myproject/myrobot
$ cd myrobot
$ ls
CMakeLists.txt  Makefile  manifest.xml  src
# Standard build (installs in the same directory as Orocos Toolchain):
  $ mkdir build ; cd build
  $ cmake .. -DCMAKE_INSTALL_PREFIX=orocos
  $ make install
# OR: ROS build:
  $ make

You can modify the .cpp/.hpp files and the CMakeLists.txt file to adapt them to your needs. See orocreate-pkg --help for other options which allow you to generate other files.

What gets generated

All files that are generated may be modified by you, except for all files in the typekit directory. That directory is generated during a build and under the control of the Orocos typegen tool, from the orogen package.

  • Makefile : default makefile to start the CMake configuration process. In case you use ROS, this file is rosmake compatible.
  • CMakeLists.txt : specify what gets build (documented in the file itself) See also our RTT Cheat Sheet
  • src/myrobot-component.cpp : template for the Myrobot component. Note that this C++ class is capitalized ('M') while the project name is lower-case ('m').
  • src/myrobot-types.hpp : put the structs/classes of communicated data in here. Restrictions apply on how such a class/struct may look like. See Typegen manual and the Orocos typekits manual.
  • typekit/ : This directory is generated by the cmake process and is under control of typegen. It contains generated code for all data found in the myrobot-types.hpp file or any other header listed in the CMakeLists.txt file.
  • Other files are examples for services and plugins and not for novice users.

Loading the component

After the 'make install' step, make sure that your RTT_COMPONENT_PATH includes the installation directory (or that you used -DCMAKE_INSTALL_PREFIX=orocos) and then start the deployer for your platform:

$ deployer-gnulinux
   Switched to : Deployer
  This console reader allows you to browse and manipulate TaskContexts.
  You can type in an operation, expression, create or change variables.
  (type 'help' for instructions and 'ls' for context info)
    TAB completion and HISTORY is available ('bash' like)
Deployer [S]> import("myrobot")
 = true
Deployer [S]> displayComponentTypes
I can create the following component types:
 = (void)
Deployer [S]> loadComponent("TheRobot","Myrobot")
Myrobot constructed !
 = true
Deployer [S]> cd TheRobot
   Switched to : TheRobot
TheRobot [S]> ls
 Listing TaskContext TheRobot[S] :
 Configuration Properties: (none)
 Provided Interface:
  Attributes   : (none)
  Operations      : activate cleanup configure error getPeriod inFatalError inRunTimeError 
isActive isConfigured isRunning setPeriod start stop trigger update 
 Data Flow Ports: (none)
 Requires Operations :  (none)
 Requests Services   :  (none)
 Peers        : (none)

Extending the component or its plugins

You now need to consult the Component Builder's Manual for instructions on how to use and extend your Orocos component. All relevant documentation is available on the Toolchain Reference Manuals page.

ROS package compatibility

The generated package contains a manifest.xml file and the CMakeLists.txt file will call ros_buildinit() if ROS_ROOT has been set and also sets the LIBRARY_OUTPUT_PATH to packagename/lib/orocos such that the ROS tools can find the libraries and the package itself. The ROS integration is mediated in the UseOrocos-RTT.cmake file, which gets included on top of the generated CMakeLists.txt file and is installed as part of the RTT. The Makefile file is rosmake compatible.

The OCL deployer knows about ROS packages and can import Orocos components (and their dependencies) from them once your ROS_PACKAGE_PATH has been correctly set.

Installing the OROCOS Toolchain (2.8) from source on Mac OSX.

Tested environments

  1. OSX Mountain Lion (10.8) (Completely clean environment in virtual machine)
  2. OSX Yosemite (10.10)

Dependency installation using Macports

Extracted from the instructions on


  • Install Apple's Developer Tools (Xcode 5 or 6).
    • 10.8: After starting Xcode select "Preferences" (?,) >> "Downloads". In "Components" you will find Command Line Tools.
    • 10.9 and 10.10: Command Line Tools are automatically installed
  • Install MacPorts
  • Add the MacPorts binary path to PATH:

echo 'export PATH=/opt/local/bin:/opt/local/sbin:$PATH' >> ~/.bash_profile 
  • Add the MacPorts library path to LIBRARY_PATH:

echo 'export LIBRARY_PATH=/opt/local/lib:$LIBRARY_PATH' >> ~/.bash_profile 
  • Clone ROS-MacPorts Repository Locally and Update MacPorts Configuration
    • First checkout an initial copy of the repository:

cd ~
git clone
    • Now we need to tell MacPorts where the local repository clone is. Do this by adding a file:///path/to/clone/location line to /opt/local/etc/macports/sources.conf:

sudo sh -c 'echo file:///Users/user/ros-macports >> /opt/local/etc/macports/sources.conf'
    • Sync the port index

sudo port sync

Resolve dependencies

  • Install and select the following ports:

sudo port install python27
sudo port select --set python python27
sudo port install boost libxslt lua51 ncurses pkgconfig readline netcdf netcdf-cxx omniORB p5-xml-xpath ros-hydro-catkin py27-sip ros-hydro-cmake_modules eigen3 dyncall ruby20
sudo port select --set nosetests nosetests27
sudo port select --set ruby ruby20
  • Open a new terminal and verify your ruby version (should be 2.0.0) :

ruby --version 
  • Verify if we use the right gem binary (should be /opt/local/bin/gem):

which gem 
sudo gem install facets nokogiri
  • Check the lua version should be 5.1 not 5.2

lua -v
  • If 5.2 uninstall lua port (which is lua 5.2)

sudo port uninstall lua

  • Install gccxml from source:

git clone
cd gccxml
mkdir build
cd build
cmake .. -DCMAKE_INSTALL_PREFIX=/opt/local
sudo make install

Build and installation of the Orocos Toolchain from source

Create a catkin workspace and get the sources

  • Create a new ros workspace for building the orocos_toolchain chained with our installed ROS Groovy workspace (which in case if the MacPorts installation is /opt/local):

mkdir -p ~/orocos_ws/src
cd ~/orocos_ws/src
sudo port install py27-wstool
wstool init .
curl | wstool merge -
wstool update
cd orocos_toolchain
git submodule foreach git checkout toolchain-2.8

Build & install the toolchain

  • Build the new workspace (the RUBY_CONFIG_INCLUDE_DIR ends with darwin12 on OSX 10.8 or darwin14 on OSX 10.10)

cd ~/orocos_ws
source /opt/local/setup.bash
sudo /opt/local/ catkin_make_isolated --install-space /opt/orocos --install --cmake-args -DENABLE_CORBA=TRUE -DCORBA_IMPLEMENTATION=OMNIORB - DRUBY_INCLUDE_DIR=/opt/local/include/ruby-2.0.0 -DRUBY_CONFIG_INCLUDE_DIR=/opt/local/include/ruby-2.0.0/x86_64-darwin13 -DRUBY_LIBRARY=/opt/local/lib/libruby2.0.dylib -DCMAKE_PREFIX_PATH="$CMAKE_PREFIX_PATH;/opt/local"

Use the toolchain

  • Source the setup.bash script from the orocos install space:

source /opt/orocos/setup.bash
  • To make sure that typegen uses the right compiler for gccxml add the following export to your ~/.bash_profile:

echo ‘export GCCXML_COMPILER=g++-mp-4.3>> ~/.bash_profile
  • You should be able to run all the tools like the deployer, typegen, rttlua and oro-createpkg

Toolchain Tutorials

RTT 2.0 Tutorial

A walkthrough of how Orocos components can be built using the RTT. Your main companion is the Orocos TaskBrowser which allows you to interactively setup and interact with an Orocos application.

These exercises are hosted on Github .

You need to have the Component Builder's Manual (see Toolchain Reference Manuals) at hand to complete these exercises.

Connecting and Running Components

Setting up applications using the deployer application

Take also at the Toolchain Reference Manuals for in-depth explanations of the deployment XML format and the different transports (CORBA, MQueue)

Using the Logging (log4cpp) infrastructure

Links to Orocos components

Configuring and Starting Components from an Orocos Script


To start an Orocos application without writing a single XML file. Note: this syntax is only possible from RTT 2.2.0 on. pre-2.2.0 versions only support scripts in 'program' blocks.

You'll need to have the Scripting Chapter of the Component Builder's Manual at hand for clarifications on syntax and execution semantics.

How it works

We write one or more scripts that locate the components on the filesystem, create them in the application and connect and configure them. We use the DeploymentComponent's scripting API to do all this, instead of using a DeploymentComponent XML file.

How it's done

Create a new file 'startup.ops'. 'ops' stands for Orocos Program Script. And write this code:

path("/opt/orocos/lib/orocos") // Path to where components are located   [1]
import("myproject")            // imports a specific project in the path [2]
import("ocl")                  // imports ocl from the path
require("print")               // loads the 'print' service globally.    [3]
loadComponent("HMI1","OCL::HMIComponent") // create a new HMI component [4]
loadComponent("Controller1","MyProjectController") // create a new controller
loadComponent("Test1","TaskContext")      // creates an empty test component

You can test this code by doing:

deployer-gnulinux -s startup.ops
OR, at the taskbrowser prompt:
Deployer [S]> help runScript 
 runScript( string const& File ) : bool
   Runs a script.
   File : An Orocos program script.
Deployer[S]> runScript("startup.ops")

The first line of startup.ops ([1]) extends the standard search path for components. Every component library directly in a path will be discovered using this statement, but the paths are not recursively searched. For loading components in subdirectories of a path directory, use the import statement. In our example, it will look for the myproject directory in the component paths and the ocl directory. All libraries and plugins in these directories will be loaded as well.

After importing, we can create components using loadComponent ([4]). The first argument is the name of the component instance, the second argument is the class type of the component. When these lines are executed, 3 new components have been created: HMI1, Controller1 and Test1.

Finally, the line require("print") loads the printing service globally such that your script can use the 'print.ln("text")' function. See help print in the TaskBrowser after you typed require("print").

Now extend the script to include the lines below. The create connection policy objects and connect ports between components.

// See the Doxygen API documentation of RTT for the fields of this struct:
var ConnPolicy cp_1
// set the fields of cp_1 to an application-specific value:
cp_1.type = BUFFER  // Use ''BUFFER'' or ''DATA''
cp_1.size = 10      // size of the buffer
cp_1.lock_policy = LOCKED // Use  ''LOCKED'', ''LOCK_FREE'' or ''UNSYNC''
// other fields exist too...
// Start connecting ports:
connect("HMI1.positions","Controller1.positions", cp_1)
cp_1 = ConnPolicy() // reset to defaults (DATA, LOCK_FREE)
connect("HMI1.commands","Controller1.commands", cp_1)
// etc...

Connecting data ports is done using ConnPolicy structs that describe the properties of the connection to be formed. You may re-use the ConnPolicy variable, or create new ones for each connection you form. The Component Builder's Manual has more details on how the ConnPolicy struct influences how connections are configured.

Finally, we configure and start our components:

if ( HMI1.configure() == false )
   print.ln("HMI1 configuration failed!")
else {
   if ( Controller1.configure() == false )
      print.ln("Controller1 configuration failed!")
   else {

Advanced configuration using a State Machine

For complexer scenarios, we can put our logic in a state machine that starts/stops/configures components as we go:
StateMachine SetupShutdown {
    var bool do_cleanup = false, could_config = false;
    initial state setup {
           entry {
                // Configure components
                could_config = HMI1.configure() && Controller1.configure();
                if (could_config) {
           transitions { 
                if do_cleanup then select shutdown;
                if could_config == false then select failure;
    state failure {
           entry {
                print.ln("Failed to configure a component!")
    final state shutdown {
           entry {
                // Cleanup B group
                HMI1.stop() ; Controller1.stop();
                HMI1.cleanup() ; Controller1.cleanup();
RootMachine SetupShutdown deployApp;

State machines are explained in detail in the Scripting Chapter of the Component Builder's Manual.

Connecting ports of components distributed with CORBA


Connecting an output port of one component with an input port of another component, where both components are distributed using the CORBA deployer application, deployer-corba.

How it works

Connecting data flow ports of components is done by defining connections (see Naming connections ). When components are distributed using the CORBA deployment component, you need to declare a proxy component in one of the deployers and connect to a port of that proxy. You only need to setup a specific connection in one XML file, the other XML files don't need to repeat the same information.

How it's done

This is your first XML file for component A. We tell that it runs as a Server and that it registers its name in the Naming Service. (See also Using CORBA and the CORBA transport reference manual for setting up naming services)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "cpf.dtd">
  <struct name="ComponentA" type="HMI">
    <simple name="Server" type="boolean"><value>1</value></simple>
    <simple name="UseNamingService" type="boolean"><value>1</value></simple>

Save this in component-a.xml and start it with: deployer-corba -s component-a.xml

This is your second XML file for component B. It has one port, cartesianPosition_desi. We add it to a connection, named cartesianPosition_desi_conn. Next, we declare a 'proxy' to Component A we created above, and we do the same for it's port, add it to the connection named cartesianPosition_desi_conn.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "cpf.dtd">
  <struct name="ComponentB" type="Controller">
    <struct name="Ports" type="PropertyBag">
      <simple name="cartesianPosition_desi" type="string">
  <!-- ComponentA is looked up using the 'CORBA' naming service -->
  <struct name="ComponentA" type="CORBA">
      <!-- We add ports of A to the connection -->
    <struct name="Ports" type="PropertyBag">
      <simple name="cartesianPosition" type="string">

Save this file as component-b.xml and start it with deployer-corba -s component-b.xml

When component-b.xml is started, the port connections will be created. When ComponentA exits and re-starts, ComponentB will not notice this, and you'll need to restart the component-b xml file as well. Use a streaming based protocol (ROS, POSIX MQueue) in case you want to be more robust against such situations.

Alternative way to do the same

You can also form the connections in a third xml file, and make both components servers like this:

Starting ComponentA:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "cpf.dtd">
  <struct name="ComponentA" type="HMI">
    <simple name="Server" type="boolean"><value>1</value></simple>
    <simple name="UseNamingService" type="boolean"><value>1</value></simple>

Save this in component-a.xml and start it with: cdeployer -s component-a.xml

Starting ComponentB:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "cpf.dtd">
  <struct name="ComponentB" type="Controller">
    <simple name="Server" type="boolean"><value>1</value></simple>
    <simple name="UseNamingService" type="boolean"><value>1</value></simple>

Save this in component-b.xml and start it with: cdeployer -s component-b.xml

Creating two proxies, and the connection:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "cpf.dtd">
  <!-- ComponentA is looked up using the 'CORBA' naming service -->
  <struct name="ComponentA" type="CORBA">
      <!-- We add ports of A to the connection -->
    <struct name="Ports" type="PropertyBag">
      <simple name="cartesianPosition" type="string">
  <!-- ComponentB is looked up using the 'CORBA' naming service -->
  <struct name="ComponentB" type="CORBA">
      <!-- We add ports of B to the connection -->
    <struct name="Ports" type="PropertyBag">
      <simple name="cartesianPosition_desi" type="string">

Save this in connect-components.xml and start it with: deployer-corba -s connect-components.xml

Further Reading

See deployer and CORBA related Toolchain Reference Manuals.

Setting up the RTT 2.4 exercises on Ubuntu

RTT Exercises Installation with ROS

These instructions are meant for the Orocos Toolchain version 2.4.0 or later.


  • Install Electric ROS using Debian packages for Ubuntu Lucid (10.04) or later. In case you don't run Ubuntu you can use the ROS install scripts. See the ros installation instructions.
    • Make sure the following debian packages are installed: ros-electric-rtt-ros-integration ros-electric-rtt-ros-comm ros-electric-rtt-geometry ros-electric-rtt-common-msgs ros-electric-pr2-controllers ros-electric-pr2-simulator ros-electric-joystick-drivers ruby
  • Create a directory in which you want to install all the workshops source (for instance training)

mkdir ~/training

  • Add this directory to your $ROS_PACKAGE_PATH


  • Get rosinstall

sudo apt-get install python-setuptools
sudo easy_install -U rosinstall

  • Get the rosinstall file . Save it as orocos_exercises.rosinstall in the training folder.
  • Run rosinstall

rosinstall ~/training orocos_exercises.rosinstall /opt/ros/electric

  • As the rosinstall tells you source the setup script

source ~/training/setup.bash

  • Install all dependencies (ignore warnings)

rosdep install youbot_common
rosdep install rFSM

  • Compile the dependencies

rosmake youbot_common rtt_dot_service rttlua_completion


  • Add the following functions in your $HOME/.bashrc file:

    source $HOME/training/setup.bash;
    source $HOME/training/;
    source /opt/ros/electric/stacks/orocos_toolchain/;
    if [ "x$LUA_PATH" == "x" ]; then LUA_PATH=";;"; fi
    if [ "x$LUA_CPATH" == "x" ]; then LUA_CPATH=";;"; fi
    export LUA_PATH="$LUA_PATH;`rospack find rFSM`/?.lua"
    export LUA_PATH="$LUA_PATH;`rospack find ocl`/lua/modules/?.lua"
    export LUA_PATH="$LUA_PATH;`rospack find rttlua_completion`/?.lua"
    export LUA_CPATH="$LUA_CPATH;`rospack find rttlua_completion`/?.so"
    export PATH="$PATH:`rosstack find orocos_toolchain`/install/bin"


You can test your setup after all the above steps by opening a new terminal and doing:
  roscd hello-1-task-execution
  rosrun ocl deployer-gnulinux -s start.ops

Using the Taskbrowser

Creating a variable

The created variables are listed as attributes to the component you created them in.
  • simple types (int, double...)

var double a
  • arrays, eg. of size 2

var float64[] b(2)

CMake and building

Your CMakeLists.txt files will be created by the orocreate-pkg tool. However, when you need to tune your build, you'll need more information which you can find below.

Finding RTT and its plugins

In order to locate RTT or one of the plugins on your filesystem, you need to modify the find_package(OROCOS-RTT REQUIRED) command to find_package(OROCOS-RTT REQUIRED <pluginlibname>). For example:
find_package(OROCOS-RTT REQUIRED rtt-marshalling)

pre-2.3.2: You may only call find_package(OROCOS-RTT ... ) once. Next calls to this macro will return immediately, so you need to specify all plugins up-front. RTT versions from 2.3.2 on don't have this limitation.

Using find_package(OROCOS-RTT)

After find_package found the RTT and its plugins, you must explicitly use the created CMake variables in order to have them in effect. This looks typically like:

# Link all targets AFTER THIS LINE with 'rtt-scripting' COMPONENT:
  message(SEND_ERROR "'rtt-scripting' not found !")
# now define your components, libraries etc...
# ...
#Prefered way to link instead of the above method:
target_link_libraries( mycomponent ${OROCOS-RTT_RTT-SCRIPTING_LIBRARY})

Or for linking with the standard provided CORBA transport:

# Link all targets AFTER THIS LINE with the CORBA transport (detected by default!) :
  link_libraries( ${OROCOS-RTT_CORBA_LIBRARIES} )
  message(SEND_ERROR "'CORBA' transport not found !")
# now define your components, libraries etc...
# ...
#Prefered way to link instead of the above method:
target_link_libraries( mycomponent ${OROCOS-RTT_RTT_CORBA_LIBRARIES})

Using other packages for building and linking (orocos_use_package)

Orocos has a system which lets you specify which packages you want to use for including headers and linking with their libraries. Orocos will always get these flags from a pkg-config .pc file, so in order to use this system, check that the package you want to depend on provides such a .pc file.

If the package or library you want to use has a .pc file, you can directly use this macro:

# The CORBA transport provides a .pc file 'orocos-rtt-corba-<target>.pc':
orocos_use_package( orocos-rtt-corba )
# Link with the OCL Deployment component:
orocos_use_package( ocl-deployment )
# now define your components, libraries etc...

This macro has a similar effect as putting this dependency in your manifest.xml file, it sets the include paths and links your libraries if OROCOS_NO_AUTO_LINKING is not defined in CMake (the default). Some packages (like OCL) define multiple .pc files, in which case you can put the ocl dependency in the manifest.xml file and use orocos_use_package() to use a specific ocl .pc file.

If the argument to orocos_use_package() is a real package, it is advised to put the dependency in the manifest.xml file, such that the build system can use that information for dependency tracking. In case it is a library as a part of a package (in this case: CORBA is a sub-library of the 'rtt' package), you should put rtt as a dependency in the manifest.xml file, and orocos-rtt-corba with the orocos_use_package macro as shown above.

find_package(OROCOS-RTT) syntax

The Orocos-RTT find macro has this API (copied from the orocos-rtt.config.cmake file of RTT):
# CMake package configuration file for the OROCOS-RTT package.
# This script imports targets and sets up the variables needed to use the package.
# In case this file is installed in a nonstandard location, its location can be 
# specified using the OROCOS-RTT_DIR cache
# entry.
# find_package COMPONENTS represent OROCOS-RTT plugins such as scripting,
# marshalling or corba-transport.
# The default search path for them is:
#  /path/to/OROCOS-RTTinstallation/lib/orocos/plugins
#  /path/to/OROCOS-RTTinstallation/lib/orocos/types
# For this script to find user-defined OROCOS-RTT plugins, the RTT_COMPONENT_PATH 
# environment variable should be appropriately set. E.g., if the plugin is located 
# at /path/to/plugins/, then add /path/to to RTT_COMPONENT_PATH
# This script sets the following variables:
#  OROCOS-RTT_FOUND: Boolean that indicates if OROCOS-RTT was found
#  OROCOS-RTT_INCLUDE_DIRS: Paths to the necessary header files
#  OROCOS-RTT_LIBRARIES: Libraries to link against to use OROCOS-RTT
#  OROCOS-RTT_DEFINITIONS: Definitions to use when compiling code that uses OROCOS-RTT
#  OROCOS-RTT_PATH: Path of the RTT installation directory (its CMAKE_INSTALL_PREFIX).
#  OROCOS-RTT_COMPONENT_PATH: The component path of the installation 
#                             <prefix>/lib/orocos + RTT_COMPONENT_PATH
#  OROCOS-RTT_PLUGINS_PATH: The plugins path of the installation 
#                           <prefix>/lib/orocos/plugins + RTT_COMPONENT_PATH * /plugins
#  OROCOS-RTT_TYPES_PATH: The types path of the installation 
#                         <prefix>/lib/orocos/types + RTT_COMPONENT_PATH * /types
#  OROCOS-RTT_CORBA_FOUND: Defined if corba transport support is available
#  OROCOS-RTT_CORBA_LIBRARIES: Libraries to link against to use the corba transport
#  OROCOS-RTT_MQUEUE_FOUND: Defined if mqueue transport support is available
#  OROCOS-RTT_MQUEUE_LIBRARIES: Libraries to link against to use the mqueue transport
#  OROCOS-RTT_VERSION: Package version
#  OROCOS-RTT_VERSION_MAJOR: Package major version
#  OROCOS-RTT_VERSION_MINOR: Package minor version
#  OROCOS-RTT_VERSION_PATCH: Package patch version
#  OROCOS-RTT_USE_FILE_PATH: Path to package use file, so it can be included like so
#                            include(${OROCOS-RTT_USE_FILE_PATH}/UseOROCOS-RTT.cmake)
#  OROCOS-RTT_USE_FILE     : Allows you to write: include( ${OROCOS-RTT_USE_FILE} )
# This script additionally sets variables for each requested 
# find_package COMPONENTS (OROCOS-RTT plugins).
# For example, for the ''rtt-scripting'' plugin this would be:
#  OROCOS-RTT_RTT-SCRIPTING_FOUND: Boolean that indicates if the component was found
#  OROCOS-RTT_RTT-SCRIPTING_LIBRARY: Libraries to link against to use this component 
#                                    (Notice singular _LIBRARY suffix !)
# Note for advanced users: Apart from the OROCOS-RTT_*_LIBRARIES variables, 
# non-COMPONENTS targets can be accessed by their imported name, e.g., 
# target_link_libraries(bar @IMPORTED_TARGET_PREFIX@orocos-rtt-gnulinux_dynamic).
# This of course requires knowing the name of the desired target, which is why using 
# the OROCOS-RTT_*_LIBRARIES variables is recommended.
# Example usage:
#  find_package(OROCOS-RTT 2.0.5 EXACT REQUIRED rtt-scripting foo) 
#               # Defines OROCOS-RTT_RTT-SCRIPTING_*
#  find_package(OROCOS-RTT QUIET COMPONENTS rtt-transport-mqueue foo)
#               # Defines OROCOS-RTT_RTT-TRANSPORT-MQUEUE_* 

Orocos CMakeLists.txt Example

This example is identical to the result of running:
orocreate-pkg example

You may remove most of the code/statements that you don't use. We only left the most common CMake macros not commented, which tells you which ones you should use most certainly when building a component:

# The find_package macro for Orocos-RTT works best with
# cmake >= 2.6.3
cmake_minimum_required(VERSION 2.6.3)
# This creates a standard cmake project. You may extend this file with
# any cmake macro you see fit.
# Set the CMAKE_PREFIX_PATH in case you're not using Orocos through ROS
# for helping these find commands find RTT.
# Defines the orocos_* cmake macros. See that file for additional
# documentation.
# Components, types and plugins.
# The CMake 'target' names are identical to the first argument of the
# macros below, except for orocos_typegen_headers, where the target is fully
# controlled by generated code of 'typegen'.
# Creates a component library libexample-<target>.so
# and installs in the directory lib/orocos/example/
orocos_component(example example-component.hpp example-component.cpp) # may add multiple source files
# You may add multiple orocos_component statements.
# Building a typekit (recommended):
# Creates a typekit library libexample-types-<target>.so
# and installs in the directory lib/orocos/example/types/
#orocos_typegen_headers(example-types.hpp) # may add multiple header files
# You may only have *ONE* orocos_typegen_headers statement !
# Building a normal library (optional):
# Creates a library libsupport-<target>.so and installs it in
# lib/
#orocos_library(support support.cpp) # may add multiple source files
# You may add multiple orocos_library statements.
# Building a Plugin or Service (optional):
# Creates a plugin library libexample-service-<target>.so or libexample-plugin-<target>.so
# and installs in the directory lib/orocos/example/plugins/
# Be aware that a plugin may only have the loadRTTPlugin() function once defined in a .cpp file.
# This function is defined by the plugin and service CPP macros.
#orocos_service(example-service example-service.cpp) # ...only one service per library !
#orocos_plugin(example-plugin example-plugin.cpp) # ...only one plugin function per library !
# You may add multiple orocos_plugin/orocos_service statements.
# Additional headers (not in typekit):
# Installs in the include/orocos/example/ directory
orocos_install_headers( example-component.hpp ) # may add multiple header files
# You may add multiple orocos_install_headers statements.
# Generates and installs our package. Must be the last statement such
# that it can pick up all above settings.