I'd like to figure out how easy it would be to use orogen as a drop-in for
libraries (like bfl/kdl/...) that need a type plugin for their C++ types.
orogen could then be included in the build step to generate the type plugin.
We'd need a slightly different interface to orogen. I would invoke it like:
rttypegen -o mytypes app/datatype1.hpp app/datatype2.hpp
Would result in the libmytypes.so file, or similar (mytypes.dll) on
non-Linux platforms. Building that library included !
Any advise on feasibility ?
Peter
rttypegen
On Thu, Nov 05, 2009 at 03:13:15PM +0100, Peter Soetens wrote:
> I'd like to figure out how easy it would be to use orogen as a drop-in for
> libraries (like bfl/kdl/...) that need a type plugin for their C++ types.
> orogen could then be included in the build step to generate the type plugin.
>
> We'd need a slightly different interface to orogen. I would invoke it like:
>
> Would result in the libmytypes.so file, or similar (mytypes.dll) on non-Linux
> platforms. Building that library included !
Isn't that basically reinventing SWIG?
Markus
rttypegen
On Thu, Nov 5, 2009 at 21:25, Markus Klotzbuecher <
markus [dot] klotzbuecher [..] ...> wrote:
> On Thu, Nov 05, 2009 at 03:13:15PM +0100, Peter Soetens wrote:
> > I'd like to figure out how easy it would be to use orogen as a drop-in
> for
> > libraries (like bfl/kdl/...) that need a type plugin for their C++ types.
> > orogen could then be included in the build step to generate the type
> plugin.
> >
> > We'd need a slightly different interface to orogen. I would invoke it
> like:
> >
> > Would result in the libmytypes.so file, or similar (mytypes.dll) on
> non-Linux
> > platforms. Building that library included !
>
> Isn't that basically reinventing SWIG?
I don't think we have the resources to add Orocos typekit generation to
SWIG.
Does Swig operate on the headers directly or do you need to create a
separate file ?
For orogen, it's mandatory to put #ifndef TYPELIB (or something) around
headers you don't want to parse, but that's about it. There's also this
issue that the class shouldn't have virtual functions, because orogen
assumes some C++ object layout. Sylvain, is this documented somewhere btw ?
Peter
rttypegen
On Thu, Nov 05, 2009 at 10:21:46PM +0100, Peter Soetens wrote:
> On Thu, Nov 5, 2009 at 21:25, Markus Klotzbuecher <
> markus [dot] klotzbuecher [..] ...> wrote:
>
> On Thu, Nov 05, 2009 at 03:13:15PM +0100, Peter Soetens wrote:
> > I'd like to figure out how easy it would be to use orogen as a drop-in
> for
> > libraries (like bfl/kdl/...) that need a type plugin for their C++ types.
> > orogen could then be included in the build step to generate the type
> plugin.
> >
> > We'd need a slightly different interface to orogen. I would invoke it
> like:
> >
> > Would result in the libmytypes.so file, or similar (mytypes.dll) on
> non-Linux
> > platforms. Building that library included !
>
> Isn't that basically reinventing SWIG?
>
>
> I don't think we have the resources to add Orocos typekit generation to SWIG.
Yes that's possible. I don't know what the efforts would be.
> Does Swig operate on the headers directly or do you need to create a separate
> file ?
While it can work on headers directly, I think commonly you create a
file which specifies to which entities in the header you want to bind
to.
> For orogen, it's mandatory to put #ifndef TYPELIB (or something) around headers
> you don't want to parse, but that's about it. There's also this issue that the
> class shouldn't have virtual functions, because orogen assumes some C++ object
> layout. Sylvain, is this documented somewhere btw ?
Markus
rttypegen
On Nov 5, 2009, at 09:13 , Peter Soetens wrote:
> I'd like to figure out how easy it would be to use orogen as a drop-
> in for libraries (like bfl/kdl/...) that need a type plugin for
> their C++ types. orogen could then be included in the build step to
> generate the type plugin.
>
> We'd need a slightly different interface to orogen. I would invoke
> it like:
>
> Would result in the libmytypes.so file, or similar (mytypes.dll) on
> non-Linux platforms. Building that library included !
>
> Any advise on feasibility ?
So "libmytypes.so" would be a plugin library? What format do you see
the datatype.hpp files being in? Would this include XML de/composition
also? What of transports? Just trying to figure out the scope here ...
This does sound like a damn fine addition to the system! :-) Plugins
are currently just a lot of grunt work ...
Stephen
rttypegen
Executive summary: see the rttypegen branch on my github's orogen repository
for a quick proof of concept
On Thursday 05 November 2009 15:22:56 S Roderick wrote:
> On Nov 5, 2009, at 09:13 , Peter Soetens wrote:
> > I'd like to figure out how easy it would be to use orogen as a drop-
> > in for libraries (like bfl/kdl/...) that need a type plugin for
> > their C++ types. orogen could then be included in the build step to
> > generate the type plugin.
> >
> > We'd need a slightly different interface to orogen. I would invoke
> > it like:
> >
> > Would result in the libmytypes.so file, or similar (mytypes.dll) on
> > non-Linux platforms. Building that library included !
> >
> > Any advise on feasibility ?
orogen itself already generates all the required stuff, so this is highly
feasible (to Stephen: right now including property composition/decomposition
and CORBA; adding other transports would require a bit of refactoring to make
it cleaner).
On the generation side, it would involve being able to change the output
directory of the Toolkit class and doing specific CMake code -- I don't think
that the orogen's cmake code is usable there.
On the interface side it would simply require orogen to ship the rttypegen
tool as well.
What would also be required is the ability to specify toolkits that needs to
be reused -- otherwise the code for base types would be regenerated N times
... Not good. That could lead to a complex command line. I personally would
prefer to just use the orogen description language instead. That would also
provide some of the advanced features of the type generation in orogen.