Wiki » History » Version 14

J. Wienke, 12/04/2010 12:48 AM

1 7 J. Wienke
h1. Prerequisites
2 1 J. Wienke
3 7 J. Wienke
h2. Dependencies
4 7 J. Wienke
5 4 J. Wienke
* Boost >= 1.38 (for hardy available in the gar-installer, 1.34.1 untested)
6 14 J. Wienke
* Boost.UUID (header-only, officially included in Boost since 1.42, headers from this version can be used with all older versions of boost, gar-installer package available)
7 4 J. Wienke
* CMake (tested with 2.8)
8 4 J. Wienke
* optional
9 4 J. Wienke
** Doxygen for API generation
10 1 J. Wienke
** Lcov for code coverage analysis
11 7 J. Wienke
12 7 J. Wienke
h2. Supported Operating Systems and Compilers
13 7 J. Wienke
14 7 J. Wienke
* Linux (GCC 4.x)
15 7 J. Wienke
* Windows (MS Visual Studio 9 2008)
16 4 J. Wienke
17 8 J. Wienke
Other combination may be possible but are currently untested.
18 8 J. Wienke
19 4 J. Wienke
h1. Contents
20 4 J. Wienke
21 6 J. Wienke
h2. Logging Adapter
22 6 J. Wienke
23 6 J. Wienke
Several different logging systems exist with different advantages and dependencies. E.g. log4cxx heavily relies on APR which is a huge dependency to built i.e. for embedded systems like Nao. To decouple libraries from concrete logging implementations and their dependencies, RSC contains a flexible adaption layer that can utilize different logging mechanisms through one interface. If e.g. log4cxx is available, a client using the RSC logging system can use log4cxx through the provided interfaces. If no versatile logging system is available, RSC falls back on a simple console logging mechanism without any dependencies. Hence, client code does not need to be recompiled for changing the logging system.
24 6 J. Wienke
25 6 J. Wienke
Currently the linker call decides which logging mechanisms are available by linking their adapter shared libraries to the client. A plugin system is planned to remove the necessity of calling the linker.
26 6 J. Wienke
27 9 J. Wienke
h2. Subprocess
28 9 J. Wienke
29 9 J. Wienke
A high-level interface for starting executables and automatically terminating them based on the RAII-pattern. The operating system is abstracted.
30 9 J. Wienke
31 9 J. Wienke
h2. Threading
32 9 J. Wienke
33 9 J. Wienke
Support classes for threading tasks like synchronized queues, a task abstraction, or a thread pools for dispatching asynchronous events with ordering guarantees.
34 9 J. Wienke
35 9 J. Wienke
h2. Misc
36 9 J. Wienke
37 9 J. Wienke
Collection of various utility classes including:
38 9 J. Wienke
* *Registry*: Key-value based registry for system components.
39 9 J. Wienke
* *UUID*: Simplified wrapper for boost::uuid.
40 9 J. Wienke
* Various utility functions for string manipulation or boost::shared_ptr handling.
41 9 J. Wienke
42 4 J. Wienke
h2. CMake Support Library
43 4 J. Wienke
44 1 J. Wienke
RSC contains different CMake scripts and macros which are generally useful. These include:
45 10 J. Wienke
* Find macros for various software packages like spread, BoostUUID, Eigen2, Log4cxx
46 2 J. Wienke
* *EnableConverageReport*: Support for html code coverage reports on GCC using gcov and lcov.
47 1 J. Wienke
* *CheckInitMethod*: Checks which compiler-specific method can be used to execute before the main method begins. This is e.g. useful to install extensions
48 1 J. Wienke
* *InstallFilesRecursive*: A macro to install files while preserving their folder structure. The normal install macro of CMake copies all given files into a flat list at the target location.
49 1 J. Wienke
* *ParseArguments*: Helper to parse arguments to CMake macros and functions with UPPERCASE keywords to separate lists.
50 1 J. Wienke
51 5 J. Wienke
All CMake files are installed to @$prefix/share/cmake/Modules@ and available in the repository at source:/trunk/rsc/cmake.