Difference between revisions of "YARP Cleanup"

From Wiki for iCub and Friends
Jump to: navigation, search
(Windows)
Line 56: Line 56:
  
 
* <span style="background:#00FF00">[Suggested]</span> We should ship external packages together with GtkMM and the other dependencies.
 
* <span style="background:#00FF00">[Suggested]</span> We should ship external packages together with GtkMM and the other dependencies.
* <span style="background:#00FF00">[Suggested]</span> We should investigate if it is possible to use [http://coapp.org/ CoApp] for building YARP packages and its dependencies
+
* <span style="background:#00FF00">[Suggested]</span> We should investigate if it is possible to use [http://coapp.org/ 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.
 
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.
 
But for now I don't know what's the best way to deal with it.

Revision as of 12:06, 14 November 2012

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


General

  • [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)

FindXXX

  • [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
  • [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).
  • [Required] Mail to the mailing lists about those changes.

Extern libraries

Debian/Ubuntu

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

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.

General

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

API/ABI

  • [Suggested] Constify methods and pass const references whenever possible. 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] Run API and ABI checker tools before every release to ensure that API and ABI are stable during the release cycle.
  • [Recommended] Mark methods as deprecated instead of modifying/removing them

Other Optional Cleanup

  • [If we have time] Replace all tabs with spaces and remove trailing spaces
  • [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