Better Repository old
Author: Lorenzo Natale
For historical reasons the iCub repository and the build system have been designed in a way that make it quite difficult to provide the functionalities of a mature package.
In parallel cmake has evolved quite a lot since version 2.4 and offers much more robust and useful features than the ones we replied upon when we started the project.
We still would like to keep at the minimum the amount of work required to maintain the repository. Users should be allowed to add new modules to the main build without much effort. However we also would like to give the possibility to use the software from other packages or libraries, in particular we would like this to be possible in two configurations: - out-of-source or in-source builds - from installation
We do a first distinction between modules that are "visible" only within the iCub repository and modules that are "exported", or in other words, can be used externally with respect to the big iCub build. Another distinction can be made between executables and libraries. Executables are easy to export: they do not provide header files or other resources. It is enough to put them in the system path. This can be done at install time, or by appending the binary directory where executables are built to the system path (something like ICUB_DIR/bin). Libraries are a bit more complicated because they define symbols, have header files and dependencies.
It is also important to stress that the iCub build is not just a normal package with a set of libraries and executables. We like to see the build more like a federation of modules, made of executables and libraries. This is how external packages view the iCub software.
Adding an executable to the build is simple, it does not take more than a few lines of cmake code:
To cope with intallation this is enough:
You should be aware that a library has a public and a private interface. The public interface is a set of header files that users of the library will include; the private interface is a set of header files that are included only by code inside the library. This distinction is important. Header files that are the public interface of the library should be clean; they should define only the minimum set of symbols required by the user, and avoid polluting the main scope with unnecessary symbols. Ideally all symbols should be hidden in a separate namespace.
It is a good idea to maintain the distinction between public and private interface at the file system level (public header files in one directory, private header files in another one).
At install time only public header files are copied to the target destination (maybe with the exception of inline files/templates which should also be visible).