[Rock-dev] Opaque type Octomap

[Sylvain Joyeux]

2014-02-25 18:15 GMT+01:00 Gabriel Alcantara <alcantara at poli.ufrj.br>:

> Hi Sylvain,
>
> I am coding the orogen/octomap package and the opaque type is really
> consuming me. Eduardo is also helping me.
>
> What I understood from the opaque type is that we need to encapsulate the
> octomap, so the orocos can understand this type, am I right?! So I tried to
> put them as an attribute of an opaque_type_octomap. I got a bunch of
> compilation erros, even with the gccxml.
>
> Then I tried to do something as a ROS msg and encapsulate like that. I
> could run the rock-orogen-create, but not the amake. I got this error
>
>  error: 'bool orogen_typekits::fromCORBA(octotype::Task_STATES&, const
> orogen::octotype::Corba::Task_STATES&)' redeclared as different kind of
> symbol
>
> the code is in this git
>
> https://github.com/OpenLEAD/OrogenOctomap.git
>


I found the problem ...
 1. you did not include any header that define octomap::OcTree. Newer
versions of orogen (in next and master) generate an error about it, but I
guess you are using stable.
 2. OcTree.h cannot be loaded by gccxml (they use a tr1 header a.k.a. some
C++11 code), and therefore cannot be loaded by orogen itself. This is a
major issue. I am going to start with replacing gccxml with clang ASAP, as
gccxml is going to really hold us back in the next years.

In the meantime, you will have to do it "the ROS way" :(:
 - create the intermediate type and the conversion functions
 - use the intermediate type directly on the ports (i.e. never the opaque)
and convert manually inside the C++ code (in the orogen tasks)

It sucks, but will allow you to go forward

Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140314/4556fc59/attachment.htm