YARP 2.4 Migration

From Wiki for iCub and Friends
Jump to navigation Jump to search

Migrating from YARP 2.3 to YARP 2.4 might require some changes to your code.

List of incompatible changes

This is a list of incompatible changes from YARP 2.3 series to YARP 2.4



cmake variable YARP_MODULE_PATH is a real "PATH" and therefore could be a list and not a single directory. This might break in a few cases (i.e. when used in include(${YARP_MODULE_PATH}/something.cmake)) There are 2 options to fix this:

  • Use the variable YARP_MODULE_DIR instead of YARP_MODULE_PATH:
  • Add YARP_MODULE_PATH to the CMAKE_MODULE_PATH variable and use the filename without the path and the extension :

Ongoing discussions


The key point here is to clearly define what should be visible and reachable from outside the library and what shouldn't.

In our understanding, the goal of this library is mainly to provide general virtual interfaces without implemetation, and some devices already implemented.
In the former category fall interfaces like IPositionControl, IVelocityControl, IFrameGrabberControlsDC1394 and so on, in the latter category falls devices like controlboard, serverInertial, remoteFrameGrabber and so on...

Those devices are meant to be instatiated by the factory and the accessed using the public interfaces, e.g.

PolyDriver poly;
poly.open("device", "controlboard");
IPositionControl *iPos;

BUT, since all headers are public and installed, an user could also instantiate devices using other methods like simply

new RemoteFrameGrabber;

and even create new classes derived from those devices.

And in fact they do.

This is a snippet from FrameGrabberGUIControl2 (iCub/tools)

class FrameGrabberGUIControl2 : public Gtk::Window, virtual public yarp::dev::RemoteFrameGrabberControlsDC1394

The same thing can be done using the "factory + interface" idea.

FrameGrabberGUIControl2::FrameGrabberGUIControl2(char* loc, char* rem)
 yarp::dev::PolyDriver grabberDev;
 yarp::dev::IFrameGrabberControlsDC1394 * iGrabber;
 yarp::os::Property config;
 config.put("device", "remote_grabber");

I did this changes in this class and it compiles fine (I haven't tried to run it, however).

   If the user needs to derive from a class instead of instantiate an object, then we probably should
   supply an abstract class and both classes should derive from that. --Daniele.Domenichelli@iit.it (talk) 15:38, 8 November 2013 (CET)

So the philosophical question is: should we allow user to do whatever he/she likes with devices or restrict the usage in the "factory + interface" fashion?

If this is the case a way of doing it is to create a subfolder for the devices with implementation and keep there their headers and implementation files without installing them.


  • User is forced to use the factory because it cannot have direct access to the real device anymore
  • Helper classes used by a device internally will not be exported in the library avoid name conflict problem from the root.


  • Derived classes that now use the other way of access devices needs to be modified
  • If derived devices need to have access to something currently not exported by the interfaces, it won't work unless the interface is expanded (btw for the FrameGrabberGui I saw it's not the case)
  • Remember this change could involve devices outside iCub repo.