This website uses browsing/session and functional cookies to ensure you get the best experience. Learn More
Organization of source code, binaries, scripts and config files
Author: Lorenzo Natale
Source files, binaries, scripts and config files are separated entities that can be placed in separate directories. This allows a better organization of your build and in turn simplifies development.
The source tree is where you download the sources, either from SVN or from a zip/tar file. Sources can be shared between users or machines. Sometimes it is convenient to share sources between machines (or users) so that changes/updates are shared by everybody.
In common situations the environment variable ICUB_ROOT points to the location of your sources (notice that is is no longer important and can be changed -- see discussion below).
Your build directory is where you place: make/project files and files that are the result of the compilation (object files, for example). This also stores libs and executables that are produced when you compile. This directory is more difficult to share, as its content changes depending on i) the compile environment used and ii) the user's choices. If you have a cluster of similar machines (same compiler, same system libraries, compatible CPU) you can share the build directory and spare time. However, if you have machines with mixed architecture (32 versus 64 bits), or that have different Linux distributions, you need two separate build trees. Your build also contains CMake files used by other projects to use the binaries (CMake files).
ICUB_DIR should point to this directory. Typically you run:
cd $ICUB_DIR cmake directory of your sources (e.g. C:/iCub/main)
Within the app directory there are some files that are private to certain robots (e.g. calibration files). They are stored in directories whose name matches that of the robot (e.g. iCubGenova01). These files should be well separated and are provided with the robot. We would like to keep them in the repository so that i) they are not lost and ii) we can update them remotely and propagate them to users.
Applications that need access to these parameters should be able to do so transparently.
Since August 2013, the localization of this robot specific directory is handled by the ResourceFinder through the YARP_ROBOT_NAME environment variable. This variable should be set to the name of your robot, e.g., for iCubGenova01 robot:
The details of how the ResourceFinder works are provided here. In short, the ResourceFinder adds robots/$YARP_ROBOT_NAME to the search path, after the current working directory and before the "contexts" directory.
Since July 2009 and up to August 2013, to use this feature you needed to set an environment variable called ICUB_ROBOTNAME that matched your robot name (e.g. iCubGenova01):
ICUB_ROBOTNAME= name of your robot
The ResourceFinder added app/$ICUB_ROBOTNAME/conf to the search path. Files were searched in this directory after the context and before app/default/conf.