Difference between revisions of "YARP 2.4 Migration"
(→CMake) |
(→CMake) |
||
Line 67: | Line 67: | ||
==== <code>add_library</code> inside a <code>PLUGIN_LIBRARY</code> block ==== | ==== <code>add_library</code> inside a <code>PLUGIN_LIBRARY</code> block ==== | ||
In order to add a plugin, in YARP 2.3 you had to use <code>add_library</code> inside a <code>YARP_{BEGIN,END}_PLUGIN_LIBRARY</code> block. | In order to add a plugin, in YARP 2.3 you had to use <code>add_library</code> inside a <code>YARP_{BEGIN,END}_PLUGIN_LIBRARY</code> block. | ||
This is no longer the recommanded way to do it and might be removed in the future, you should use <code>yarp_add_plugin</code> instead. | This is no longer the recommanded way to do it and might be removed in the future, you should use <code>yarp_add_plugin</code> instead. | ||
==== Imported Targets ==== | |||
In YARP 2.3 and previous versions, YARP cmake target were exported without namespace, starting from YARP 2.4 they are exported with the "YARP::" namespace. Therefore you can no longer link <code>YARP_OS</code>, but you have to link <code>YARP::YARP_OS</code>. If you are linking the <code>${YARP_LIBRARIES}</code> variable, the behaviour is not changed. |
Revision as of 18:16, 26 March 2014
This page is still work in progress and may change.
Migrating from YARP 2.3 to YARP 2.4 might require some changes to your code. Notice that before the release of YARP 2.4 these changes are in the master branch of the repository (version 2.3.60).
Changes in YARP
- The main different was in the policy used in YARP to organize and search for configuration files has changed heavily: see ResourceFinder
- Devices:
controlBoardWrapper2 analogServer virtualAnalogServer
from icubmod have been moved to YARP. The versions in icubmod are deprecated and will be removed.
- Added new interfaces for:
- Controlling subset of joints IPositionControl2, IVelocityControl2
- Control the position directly (bypassing the minimum-jerk trajecotory generator) IPositionDirect
- Full revision of yarprun. Notice: now when you run yarprun server (e.g. yarprun --server /node) two processes with the same name are created and appear in the process list (the first one to receive commands and the second to fork processes). This is normal.
Things that change in iCub
- ICUB_ROOT
- Remove references to ICUB_ROOT in ResourceFinder configuration
- No need to set ICUB_ROOT environment variable
- $ICUB_ROOT/ICUB_ROOT.ini is obsolete
- Files that used to be in $ICUB_ROOT/app are now in $ICUB_DIR/app or installed in /usr/local with the binaries (depending on how you compile the code) (see changes to the ResourceFinder in the previous section). If existing old files in $ICUB_ROOT/app should be removed.
- Target install_application and ICUB_INSTALL_APPLICATIONS CMake flag removed, now applications and other files are with the binaries both in the build and in the installation directory
- Updated installation instructions:
- Repository description Better_Repository and CMake templates in particular have been updated:
Simple template for modules in main
Simple template for libraries in main
Simple template for modules in contrib
Simple template for libraries in contrib
- Improved but changed compilation of modules in contrib. Before you compile modules in contrib you have to set up the contrib package (this is described in the installation instructions)
- CMake functions for applications like icub_app()/icub_app_install() are obsolete, use yarp_install() instead
- YARP_ROBOT_NAME environment variable replaces ICUB_ROBOTNAME
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 ofYARP_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)
add_library
inside a PLUGIN_LIBRARY
block
In order to add a plugin, in YARP 2.3 you had to use add_library
inside a YARP_{BEGIN,END}_PLUGIN_LIBRARY
block.
This is no longer the recommanded way to do it and might be removed in the future, you should use yarp_add_plugin
instead.
Imported Targets
In YARP 2.3 and previous versions, YARP cmake target were exported without namespace, starting from YARP 2.4 they are exported with the "YARP::" namespace. Therefore you can no longer link YARP_OS
, but you have to link YARP::YARP_OS
. If you are linking the ${YARP_LIBRARIES}
variable, the behaviour is not changed.