[Rock-dev] Decision on the fate of external/ ?

Sylvain Joyeux bir.sylvain at gmail.com
Mon Sep 8 14:37:49 CEST 2014


> The Problem i have with some packages like "gdal" is that there are
> neither a driver nor a "slam/whatever".
Why not ? gdal is a map management / access library. It is as much
relevant to slam/ than envire is.

> Another problem is "aravis" aravis is a library that is needed by the
> camera_aravis driver, which is needed by drivers/orogen/aravis.
Again, point of view of "in" Rock vs. "out" Rock. From the aravis website:

   Aravis is a glib/gobject based library for video acquisition using
Genicam cameras.

This is a driver, with absolutetly zero doubt.

> It's really hard to take a decimation here because as you already
> mentions some packages could not really sorted into categories (like
> gdal/yaml), putting them in tools/ makes no real difference for me,
> pcl/kdtree yould also be only a "tool", kdtree could be used for image
> processing too for example.
Some packages cannot be put in *existing* categories. I'll give the
same answer that I gave to Janosch about box2d: what when someone Rock
developer something "like" kdtree ? Where we'll put it ?

> I thing we should find a way to handle packages that are purly
> downloaded and build by rock (maybe patches), and handle them
> separately.
Yes, and I like Leif's answer to that:

     Since hopefully the rock community will grow and get more heterogeneous,
     the differentiation between internal and external seems obsolete,

You *are* trying to differentiate between "us" and "them". If we want
the community to strive, that difference needs to go away.

Sylvain


More information about the Rock-dev mailing list