This work package contains structural clean-ups for the RTT source code, such as CMake build system, portability and making the public interface slimmer and explicit. RTT 2.0 is an ideal mark point for doing such changes. Most of these reorganizations have broad support from the community. This package is put up front because it allows early adopters to switch only at the beginning to the new code structure and that all subsequent packages are executed in the new structure.

Links : (various posts on Orocos mailing lists)

Allocated Work : 15 days

Tasks:

1.1 Partition in name spaces and hide internal classes in subdirectories.

A namespace and directory partitioning will once and for all separate public RTT API from internal headers. This will provide a drastically reduced class count for users, while allowing developers to narrow backwards compatibility to only these classes. This offers also the opportunity to remove classes that are for internal use only but are in fact never used.

Deliverable	Title	Form
1.1.1	Internal headers are in subdirectories	Patch set
1.1.2	Internal classes are in nested namespaces of the RTT namespace	Patch set

1.2 Improve CMake build system

Numerous suggestions have been done on the mailing list for improving portability and building Orocos on non standard platforms.

Deliverable	Title	Form
1.2.1	Standardized on CMake 2.6	Patch set
1.2.2	Use CMake lists instead of strings	Patch set
1.2.3	No more use of Linux specific include paths	Patch set
1.2.4	Separate finding from using libraries for all RTT dependencies	Patch set

1.3 Group user contributed code in rtt/extras.

This directory offers variants of implementations found in the RTT, such as new data type support, specialized activity classes etc. In order not to clutter up the standard RTT API, these contributions are organized in a separate directory. Users are warned that these extras might not be of the same quality as native RTT classes.

Deliverable	Title	Form
1.3.1	Orocos rtt-extras directory	Directory in RTT

1.4 Improve portability

Some GNU/GCC/Linux specific constructs have entered the source code, which makes maintenance on and portability to other platforms a harder task. To structurally support other platforms, the code will be compiled with another compiler (non-gnu) and a build flag ORO_NO_ATOMICS (or similar) is added to exclude all compiler and assembler specific code and replace it with ISO-C/C++ or RTT-FOSI compliant constructs.

Deliverable	Title	Form
1.4.1	Code compiles on non-gnu compiler	Patch set
1.4.2	Code compiles without assembler constructs	Patch set

1.5 Default to activity with one thread per component

The idea is to provide each component with a robust default activity object which maps to exactly one thread. This thread can periodically execute or be non periodic. The user can switch between these modes at configuration or run-time.

Deliverable	Title	Form
1.5.1	Generic Activity class which is by default present in every component.	Patch set
1.5.2	Unit test for this class	Patch set

1.6 Standardize on Boost Unit Testing Framework

Before the other work packages are started, the RTT must standardize on a unit test framework. Until now, this is the CppUnit framework. The more portable and configurable Boost UTF has been chosen for unit testing of RTT 2.0.

Deliverable	Title	Form
1.6.1	CppUnit removed and Boost UTF in place	Patch set

1.7 Provide CMake macros for applications and components

When users want to build Orocos components or applications, they require flags and settings from the installed RTT and OCL libraries. A CMake macro which gathers these flags for compiling an Orocos component or application is provided. This is inspired on how ROS components are compiled.

Deliverable	Title	Form
1.7.1	CMake macro	CMake macro file
1.7.2	Unit test that tests this macro	Patch set

1.8 Allow lock-free policies to be configured

Some RTT classes use hard-coded lock-free algorithms, which may be in the way (due to resource restrictions) for some embedded systems. It should be possible to change the policy to not use a lock-free algorithm in that class (cfr the 'strategy' design pattern'). An example is the use of AtomicQueue in the CommandProcessor.

Deliverable	Title	Form
1.8.1	Allow to set/override lock-free algorithm policy	patch