[Rock-dev] Rock.cmake

[Sylvain Joyeux]

On 04/18/2011 03:07 PM, Peter Soetens wrote:
> See typo. If we look at the plan without looking at any technical
> solution/problem, the plan is to install/run the ros/orocos/rock combo in any
> order, from sources. We want users to be able to expore the Orocos toolchain
> (on Linux) without any hickups, rebuilds or build system conflicts.
>
> Part of this plan is also based on the 'openness' of the ros build system: you
> don't need a file that describes your project layout or version control
> settings. Just 'unzipping' a package in your ROS_PACKAGE_PATH is enough
> to have it known and used by all tools and other packages. The only file it
> requires is an os-dependencies file that lists how to resolve these. So that's
> why we're looking into using autoproj/orogen in such an 'open' system.
> autoproj controls part of the packages, but they are located in a
> ROS_PACKAGE_PATH, such that whatever autoproj/orogen installs/generates is
> picked up as well.
Sounds good.

I've also toyed with the idea of making autoproj handle ROS packages and 
stacks (since some projects at our lab are using ROS packages). autoproj 
would interface with rosmake to build ROS packages "the ros way" and 
build the rest "the normal way".

For the "orocos toolchain is installed and user wants to install rock", 
it is -- at least for now -- hard. This is so because new toolchain 
releases regularly break the rock tools, so -- for now -- I plan to keep 
rock's copy of the toolchain as the "rock orocos toolchain", not use the 
orocos toolchain directly. Simply because I can't guarantee that rock 
tools will work with the "official" toolchain. That should change in the 
future, hopefully.

>> Until we get to the point that orogen components can run on ROS, which
>> the current ROS transport does *not* provide, I don't see how the build
>> system has any influence in that respect. But anyway.
>
> The ROS transport does not provide that, but we can have orocos components
> that speak both ROS and structs with typegen generated typekits. I understand
> this component can not be generated by orogen, since orogen must understand
> all types on all ports ? (unless we add the port in the user subclass?)
It can be done by adding ports manually in the subclass. But YUK (very 
very YUK).

Nobody at KULeuven is interested in adding the necessary support in 
orogen to generate/use ROS transports ?
-- 
Sylvain Joyeux (Dr.Ing.)
Space & Security Robotics

!!! Achtung, neue Telefonnummer!!!

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 178-454136
Fax:   +49 (0)421 218-454150
E-Mail: robotik at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.:    DE 148646973
Steuernummer:  19/673/0060/3
-----------------------------------------------------------------------