YARP Cleanup

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

NOTE: THIS PAGE IS A DRAFT --Daniele.Domenichelli@iit.it 15:17, 14 November 2012 (CET)

This is a list of issues that are required and/or desirable in order to cleanup YARP, and to make it easier to package, and appealing for other projects.


  • [Required] Create yarp-devel mailing list and mail to the rc-hackers mailing list

CMake 2.6.0

  • [Required] At the moment YARP is not compiling with cmake 2.6.0, but officially we are supporting it. Moreover internally it searches for cmake 2.6.4. My suggestion is to procede in this way:
    • Fix the actual issue with cmake 2.6.0.
    • Release 2.3.20.
    • Write a mail to the mailing list about the new policies for supported debian/ubuntu releases.
    • Add a wiki page for supported versions.
    • Check if the build machines for the new policy are available and eventually add them.
    • Create 2.3 stable branch and start development of 2.4 series in trunk.
    • Bump cmake version to 2.6.4.
    • Cleanup and remove all workarounds for cmake 2.6.0.
    • Ensure that everywhere 2.6.4 is required (in all code and documentation).
    • Ensure that after those changes, YARP actually builds with cmake 2.6.4 (check the dashboard)


  • [Recommended] Fix all the FindXXX.cmake files dropping compatibility, according to CMake_Modules_Guidelines
  • [Recommended] Remove ACE4YARP
  • [Recommended] Use FeatureSummary and replace the YARP_USE_XXX and YARP_SKIP_ACE with HAVE_XXX
  • [Optional] Investigate if FindGtk shipped with cmake can be used instead of our homemade version, and eventually fix it upstream.
  • [Required] Mail to the mailing lists about those changes.

Dependency Issues

If you link libYARP_os, you don't need to link directly to ACE, unless you are using it directly in your code. So the aim here is to fix wherever libraries not needed are linked, in order to reduce the dependencies needed for debian packages (in this case you don't need the libace-dev package containing the libACE.so file)

  • [Recommended] Use LINK_PRIVATE in order not to link unneeded packages.
  • [Recommended] Create and export variables YARP_OS_LIBRARY, and use them instead of YARP_LIBRARIES
  • [Recommended] Ensure that all packages are linked internally using only the required packages and not using YARP_LIBRARIES
  • [Required] Mail to the mailing lists about those changes.

Plugin framework

Current plugin framework has several issues with dependencies. The solution would be to have plugins that are loaded dynamically and not linked statically (RUNTIME option is still not a solution because if one .so file is deleted, the library crashes, therefore the dependencies are still the same).

  • [Recommended] Rewrite plugin framework that does not require to link everything from every carrier and device. libYARP_init can be dropped if the plugin framework is implemented properly.
  • [Suggested] Remove all the non-free plugin stuff and put it in another repository. (This would be necessary to have yarp in the free section of debian repository, and the nvidia/cuda plugins in the contrib section, otherwise the whole yarp should be in contrib). When plugins will be loaded at runtime, there will be no problem in keeping them separate.
  • [Required] Mail to the mailing lists about those changes.

Extern libraries


There are a few issues with extern libraries in Debian/Ubuntu:

  1. TinyXML is required both by YARP and iCub, and the version installed with squeeze is too old.
  2. OpenCV requires several flags, and not all of them are supported in all debian/ubuntu versions.
  3. GtkDataboxMM is packaged only for Debian Testing.

At the moment I don't know how to solve these issues, the ideal solution would be not to have them in YARP/iCub and have only the FindXXX.cmake for them. But to arrive to this goal,

  • [Recommended] We should have apt repositories with dependencies with the debian/ubuntu versions that we support. In those repositories we should have the required versions of the external libraries.
  • [Recommended] We should work a lot together with packagers for Debian/Ubuntu to get the versions and the build flags that we need in the upstream packages.


Windows is a problem by itself, but on this issue, it is relatively safe, since we are already shipping binaries for most of the external libraries.

  • [Suggested] We should ship external packages together with GtkMM and the other dependencies.
  • [Suggested] We should investigate if it is possible to use CoApp for building YARP packages and its dependencies (website seems to be dead at the moment)

If one day we manage to do so, we could remove all the extern stuff and keep that in some external repository. But for now I don't know what's the best way to deal with it.


  • [Proposal] Move external dependencies in a "robocub-support" repository (to be installed before YARP and ICUB).

Most of this stuff is not required for packaging for linux distro, because it's already there. Moreover Debian policies require to remove all non-free stuff and all binary blobs, therefore the tarball released might have to be repackaged downstream. Handling this in an external repository might make things easier. From this repository we can check if a package is not installed, and eventually build and install a private version of that package.


  • [Suggested] Constify methods and pass const references whenever possible before the 2.4.0 release. For example
    • virtual bool open(Searchable& config) should probably be virtual bool open(const Searchable& config)
    • virtual Bottle& findGroup(const char *key) should probably be virtual const Bottle& findGroup(const char *key) const
  • [Suggested] Starting with the 2.4 series we should run API and ABI checker tools before every release to ensure that API and ABI are stable during the release cycle.
    • Methods should be marked as deprecated instead of modifying/removing them, and eventually removed in a major release, after a reasonable amount of time.
  • [Suggested] Do not install private headers (impl)
    • People should not rely on those headers that should contain pure implementative details.
    • If someone requires parts of them, we should consider moving that part to the public headers.
  • [Check] visibility=hidden should be used by default and only the public methods should be exported.
  • [Check] Exported classes should not contain private members and methods, since those are implementation details (see 1 and 2).

Other Optional Cleanup

  • [If we have time] Replace all tabs with spaces and remove trailing spaces
  • [If we have time] Coding style (brackets, etc.)
  • [If we have time] Headers should should not require other headers before in order to compile
  • [If we have time] Headers should contain the minimum amount of other headers, using forward declarations where possible.
  • [If we have time] Remove packaging stuff from the main repository.
  • [If we have time] Not all the classes/features in YARP are covered by unit tests, we should add them
  • [In my dreams] We should migrate to Git