Difference between revisions of "YARP 2.4 Migration"

From Wiki for iCub and Friends
Jump to: navigation, search
(Created page with "{{Under_construction}} 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 change...")
 
Line 18: Line 18:
 
     include(something)
 
     include(something)
  
=== C++ ===
+
 
 +
== Ongoing discussions ==
 +
 
 +
=== libYARP_dev ===
 +
 
 +
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. <br>
 +
In the former category falls interfaces like <code>IPositionControl, IVelocityControl, IFrameGrabberControlsDC1394 </code> and so on, in the latter category falls devices like <code>controlboard, serverInertial, remoteFrameGrabber</code> 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;
 +
poly.view(iPos);
 +
iPos->...
 +
 
 +
BUT, since all headers are public and installed, an user could also instantiate devices using other methods like simply <br>
 +
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("remote",rem);
 +
  config.put("local",loc);
 +
  config.put("device", "remote_grabber");
 +
  grabberDev.open(config);
 +
  grabberDev.view(iGrabber);
 +
  iGrabber->XXX
 +
}
 +
 
 +
I did this changes in this class and it compiles fine (I haven't tried to run it, however).
 +
 
 +
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 they headers and implementation files without installing them.
 +
 
 +
Pros:
 +
* 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.
 +
 
 +
Cons:
 +
* 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.

Revision as of 15:06, 8 November 2013

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

YARP_MODULE_PATH

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:
    include(${YARP_MODULE_DIR}/something.cmake)
  • Add YARP_MODULE_PATH to the CMAKE_MODULE_PATH variable and use the filename without the path and the extension :
    set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${YARP_MODULE_PATH})
    include(something)


Ongoing discussions

libYARP_dev

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 falls 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;
poly.view(iPos);
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("remote",rem);
 config.put("local",loc);
 config.put("device", "remote_grabber");
 grabberDev.open(config);
 grabberDev.view(iGrabber);
 iGrabber->XXX
}

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

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 they headers and implementation files without installing them.

Pros:

  • 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.

Cons:

  • 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.