Coder Social home page Coder Social logo

robotology / robotology-superbuild Goto Github PK

View Code? Open in Web Editor NEW
46.0 7.0 47.0 2.3 MB

CMake/YCM-based superbuild to simplify the build process of robotology projects.

CMake 81.13% Shell 8.55% PowerShell 0.57% Batchfile 1.07% Python 5.10% MATLAB 3.59%
superbuild ycm robotology cmake robotics

robotology-superbuild's Introduction

robotology-superbuild

This is a meta repository (so-called "superbuild") that uses CMake and YCM to automatically download and compile software developed in the robotology GitHub organization, such as the YARP middleware or software used to run the iCub humanoid robot.

CMake is an open-source, cross-platform family of tools designed to build, test and package software. A YCM Superbuild is a CMake project whose only goal is to download and build several other projects. If you are familiar with ROS, it is something similar to catkin or colcon workspace, but using pure CMake for portability reasons and for customizing the build via CMake options. Furthermore, the robotology-superbuild also contains some infrastructure to build binaries of the contained projects for some platforms. You can read more about the superbuild concept in YCM documentation or in the related IRC paper.

System Continuous Integration Status
Linux/macOS/Windows GitHub Actions Status

Table of Contents

Superbuild

The robotology-superbuild is an infrastructure to simplify development and use of open source research software developed at the Italian Institute of Technology, in particular as part of the iCub project.

Profiles and Optional Dependencies

As a huge number of software projects are contained in the robotology-superbuild, and a tipical user is only interested in some of them, there are several options to instruct the superbuild on which packages should be built and which one should not be built. In particular, the robotology-superbuild is divided in different profiles, that specify the specific subset of robotology packages to build. You can read more on the available profiles and how to enable them in the doc/cmake-options.md#profile-specific-documentation.

Furthermore, some dependencies of software contained in the robotology-superbuild are either tricky to install or proprietary, and for this reason software that depends on those optional dependencies can be enabled or disabled with specific options,as documented in doc/cmake-options.md#dependencies-specific-documentation.

Versioning

For what regards versioning, software in the robotology-superbuild can be consumed in two forms:

In this form, the superbuild will get the latest changes for a branch of each subproject, and will build it. This has the advantage that you get all the latest changes from the software contained in the robotology-superbuild, while the downside that the specific software that you use may change at each update. The rolling update can be used only when building robotology-superbuild software from source. By default, the robotology-superbuild uses the latest "stable" branches of the robotology repositories, but in some cases it may be necessary to use the "unstable" active development branches. For this advanced functionalities, please refer to the documentation on changing the default project tags, available at doc/change-project-tags.md.

Once every three months, a set of releases of the software in the robotology-superbuild is freezed and used as a "Distro Release", following the policies of iCub software described in https://icub-tech-iit.github.io/documentation/sw_versioning_table/ . Releases can be used both when building the software from source, and when obtaining it from binaries.

The available releases can be seen on GitHub's release page.

Binary Installation

We provide binary packages for Linux, macOS and Windows of the software contained in the robotology-superbuild via the conda package manager, relying on the community-mantained conda-forge channel and for some packages on our own robotology conda channel.

Please refer to doc/conda-forge.md document for instructions on how to install the conda binary packages, in particular the Binary Installation section.

Note that the default binary installed by the conda package manager is the latest available, so if you need to get exactly the version corresponding to a specific robotology-superbuild distro release (for example for compatibility with an existing robot setup), please install the required versions by inspecting the version tables of the specific distro you are interested in https://icub-tech-iit.github.io/documentation/sw_versioning_table/ .

If you need to use the robotology packages with dependencies provided by other package managers, for example with the aptpackages on Debina/Ubuntu distributions, please install robotology-superbuild from source code as explained in the approprate section, as we do not provide binary packages for all software contained in the robotology-superbuild for the apt package manager.

We also support a deprecated way of installing binary packages just on Windows using dependencies provided by vcpkg, documentation for it can be found in doc/deprecated-installation-methods.md. However for new deployments we recommend to use conda binary packages also on Windows.

Source Installation

Clone the repo

The first step to install robotology-superbuild from source is to download the robotology-superbuild code itself, and this is done through Git.

Once you install Git, you need to set your name and email to sign your commits, as this is required by the superbuild:

git config --global user.name FirstName LastName
git config --global user.email [email protected]

Once git is configured, you can open a command line terminal. If you want to use the robotology-superbuild in rolling update mode, just clone the superbuild:

git clone https://github.com/robotology/robotology-superbuild

this will clone the superbuild in its default branch.

You can download and use the robotology-superbuild anywhere on your system, but if you are installing it on an iCub robot laptop following the official iCub instructions, you should clone it in the /usr/local/src/robot directory.

If instead you want to use a specific release of the robotology superbuild, after you clone switch to use to a specific release tag:

git checkout v<YYYY.MM>

For the list of actually available tags, see the GitHub's releases page.

Once you cloned the repo, to go forward you can follow the different instructions on how to install robotology-superbuild from the source code, depending on your operating system and the package manager you want to use to install the required dependencies:

The exact versions of the operating systems supported by the robotology-superbuild follow the one supported by the YARP library, that are documented in https://github.com/robotology/yarp/blob/master/.github/CONTRIBUTING.md#supported-systems .

Complete documentation on how to use a YCM-based superbuild is available in the YCM documentation.

When compiled from source, robotology-superbuild will download and build a number of software. For each project, the repository will be downloaded in the src/<package_name> subdirectory of the superbuild root. The build directory for a given project will be instead the src/<package_name> subdirectory of the superbuild build directory. All the software packages are installed using the install directory of the build as installation prefix.

We also support an additional deprecated way of compiling the superbuild, on Windows using dependencies provided by vcpkg. Documentation for them can be found in doc/deprecated-installation-methods.md.

Linux from source with dependencies provided by apt

The following apt-based distributions are supported and tested by the robotology-superbuild:

  • Ubuntu 20.04 (Focal Fossa)
  • Ubuntu 22.04 (Jammy Jellyfish)
  • Debian 11 (Bullseye)

Other versions may be working, but they are not checked.

System Dependencies

On Debian based systems (as Ubuntu) you can install the C++ toolchain, Git, CMake and Eigen (and other dependencies necessary for the software include in robotology-superbuild) using apt-get. This can be done by installing the packages listed in the apt.txt file using the following script:

cd robotology-superbuild
sudo bash ./scripts/install_apt_dependencies.sh

Besides the packages listed in apt.txt file, the script install_apt_dependencies.sh also installs some other packages depending on the distribution used, please inspect the script for more information.

For what regards CMake, the robotology-superbuild requires CMake 3.16 . If you are using a recent Debian-based system such as Ubuntu 20.04, the default CMake is recent enough and you do not need to do further steps.

If instead you use an older distro in which the default version of CMake is older, you can easily install a newer CMake version in several ways. For the following distributions, we recommend the following methods:

For some profile or dependency specific CMake option you may need to install additional system dependencies, following the dependency-specific documentation listed in the following. If you do not want to enable an option, you should ignore the corresponding section and continue with the installation process.

Note that the ROBOTOLOGY_USES_GAZEBO option is enabled by default (except on Ubuntu 24.04 when installing with apt dependencies), so you should install Gazebo Classic unless you plan to disable this option.

ROBOTOLOGY_USES_GAZEBO

On Linux with apt dependencies install Gazebo Classic, if you are on:

  • Ubuntu 20.04

follow the instructions available at https://gazebosim.org/tutorials?tut=install_ubuntu . Make sure to install also the development files, i.e. libgazebo*-dev on Debian/Ubuntu.

Otherwise, if you are on other supported Debian/Ubuntu systems, just install the system provided gazebo package with:

sudo apt install libgazebo-dev

If you are on Ubuntu 24.04, please use conda if you want to install Gazebo Classic, as no Gazebo Classic packages are available via apt.

ROBOTOLOGY_USES_GZ

To install Modern Gazebo (gz-sim) on Ubuntu Jammy (22.04) and Noble (20.04) and other supported Debian/Ubuntu systems, follow the instructions available at https://gazebosim.org/docs/harmonic/install_ubuntu#binary-installation-on-ubuntu .

ROBOTOLOGY_USES_PYTHON

Install Python and the necessary development files using the following command:

cd robotology-superbuild
sudo bash ./scripts/install_apt_python_dependencies.sh

ROBOTOLOGY_USES_PCL_AND_VTK

On any Debian or Ubuntu based system, install PCL and VTK via

sudo apt install libpcl-dev

ROBOTOLOGY_USES_OCTAVE

Install octave and the necessary development files using the following command:

sudo apt-get install octave-dev

Compile the superbuild

Finally it is possible to install robotology software using the YCM superbuild:

cd robotology-superbuild
mkdir build
cd build
ccmake ../
make

You can configure the ccmake environment if you know you will use some particular set of software (put them in "ON"). See Superbuild CMake options for a list of available options.

Configure your environment

The superbuild provides an automatically generated setup.sh sh script that will set all the necessary enviromental variables to use the software installed in the robotology-superbuild. To do so automatically for any new terminal that you open, append the following line to the .bashrc file:

source <directory-where-you-downloaded-robotology-superbuild>/build/install/share/robotology-superbuild/setup.sh

To use the updated .bashrc in your terminal you should run the following command:

user@host:~$ source ~/.bashrc

If may also be necessary to updates the cache of the dynamic linker:

user@host:~$ sudo ldconfig

If for any reason you do not want to use the provided setup.sh script and you want to manage your enviroment variables manually, please refer to the documentation available at doc/environment-variables-configuration.md .

Linux, macOS or Windows from source with dependencies provided by conda-forge

Please refer to doc/conda-forge.md document for instruction on how to compile the superbuild from source using the conda-forge provided dependencies, in particular the Source Installation section.

Windows Subsystem for Linux from source

The Windows Subsystem for Linux (wsl) lets developers run a GNU/Linux environment -- including most command-line tools, utilities, and applications -- directly on Windows, unmodified.

As all the software running on Linux distributions can run unmodified on Windows via WSL, to install the robotology-superbuild in WSL you can just install a Debian-based distribution for WSL, and then follow the instructions on how to install the robotology-superbuild on Linux, with dependencies provided either by apt or by conda. As the WSL enviroment is nevertheless different, there are a few things you need to care before using the robotology-superbuild on WSL.

Note that in the following we assume that you have configure your WSL to run graphical applications, as documented in https://learn.microsoft.com/en-us/windows/wsl/tutorials/gui-apps .

Sanitize PATH enviroment variable for WSL

By default, the PATH enviroment variable in WSL will contain the path of the host Windows system, see microsoft/WSL#1640 and microsoft/WSL#1493. This can create problems, as the CMake in WSL may find (incompatible) Windows CMake packages and try to use them, creating errors due to the compilation. To avoid that, you can create in your WSL2 instance the /etc/wsl.conf file, and then populate it with the following content:

[interop]
appendWindowsPath = false

Note that you will need to restart your machine to make sure that this setting is taked into account.

Connect to a YARP server on a Windows host on WSL

If you want your YARP applications on WSL to connect to a yarpserver that you launched on the Windows native host (so on Command Prompt, not on WSL), you need to add the following line to your WSL's ~/.bashrc:

export WINDOWS_HOST=$(grep nameserver /etc/resolv.conf | awk '{print $2}')
yarp conf ${WINDOWS_HOST} 10000 > /dev/null 2>&1

Important: do not use this line if you are launching yarpserver directly on WSL.

Update

If you are using the robotology-superbuild in its default branch and not from a release tag (i.e. in rolling update mode), to update the superbuild you need to first update the robotology-superbuild repository itself with the git command:

git pull

After that, you will need to also run the equivalent of git pull on all the repositories managed by the robotology-superbuild, you have to run in your build system the appropriate target.

To do this, make sure to be in the build directory of the robotology-superbuild and run:

make update-all
make

using make on Linux or macOS or

cmake --build . --target ALL_UPDATE
cmake --build .

using Visual Studio on Windows or

cmake --build . --target ALL_UPDATE
cmake --build .

using Xcode on macOS.

Note that the update will try to update all the software in the robotology-superbuild, and it will complain if the repository is not in the expected branch. For this reason, if you are activly developing on a repository managed by the robotology-superbuild, remember to switch the YCM_EP_DEVEL_MODE_<package_name> option to TRUE. This option will ensure that the superbuild will not try to automatically update the <package_name> repository. See https://robotology.github.io/ycm/gh-pages/git-master/manual/ycm-superbuild.7.html#developer-mode for more details on this options.

By default, the robotology-superbuild uses the latest "stable" branches of the robotology repositories, but in some cases it may be necessary to use the "unstable" active development branches, or use some fixed tags. For this advanced functionalities, please refer to the documentation on changing the default project tags, available at doc/change-project-tags.md.

FAQs

FAQs for robotology-superbuild can be found at doc/faqs.md.

For questions related to how to modify the rootology-superbuild itself, such as how to add a new package, how to do a release, check the Developers' FAQs document at doc/developers-faqs.md.

As robotology-superbuild is based on YCM, also YCM's FAQs could be relevant.

Mantainers

robotology-superbuild's People

Contributors

actions-user avatar albertoremus avatar alexantn avatar bemilio avatar danielepucci avatar dependabot[bot] avatar diegoferigo avatar drdanz avatar fiorisi avatar gabrielenava avatar giotherobot avatar github-actions[bot] avatar giulioromualdi avatar julijenv avatar kouroshd avatar lauracavaliere avatar lrapetti avatar martinaxgloria avatar mbrunettini avatar nicogene avatar nunoguedelha avatar pattacini avatar prashanthr05 avatar riccardogrieco avatar s-dafarra avatar sgiraz avatar traversaro avatar valegagge avatar xela-95 avatar xenvre avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

robotology-superbuild's Issues

Add minimal macOs CI job

It can be either Jenkins or Travis, but it should also test ROBOTOLOGY_USES_GAZEBO, especially now that Gazebo is distributed as a bottle in homebrew. Hopefully we should avoid to miss to catch issues such as osrf/homebrew-simulation#384 in the future.

YCM error with CMake 3.2

CMake Error at build/install/share/YCM/cmake-next/Modules/FindPackageHandleStandardArgs.cmake:132 (include):
  include could not find load file:
    /home/travis/build/traversaro/robotology-superbuild/build/install/share/YCM/cmake-next/Modules/FindPackageMessage.cmake
Call Stack (most recent call first):
  build/install/share/YCM/modules/StandardFindModule.cmake:88 (include)
  build/install/share/YCM/find-modules/FindACE.cmake:41 (include)
  cmake/BuildYARP.cmake:8 (find_package)
  build/install/share/YCM/modules/FindOrBuildPackage.cmake:235 (include)
  CMakeLists.txt:105 (find_or_build_package)
-- Performing Test ACE_COMPILES_WITHOUT_INLINE_RELEASE
-- Performing Test ACE_COMPILES_WITHOUT_INLINE_RELEASE - Success
CMake Error at build/install/share/YCM/cmake-next/Modules/FindPackageHandleStandardArgs.cmake:132 (include):
  include could not find load file:
    /home/travis/build/traversaro/robotology-superbuild/build/install/share/YCM/cmake-next/Modules/FindPackageMessage.cmake

Call Stack (most recent call first):
  build/install/share/YCM/3rdparty/FindEigen3.cmake:91 (include)
  cmake/BuildYARP.cmake:10 (find_package)
  build/install/share/YCM/modules/FindOrBuildPackage.cmake:235 (include)
  CMakeLists.txt:105 (find_or_build_package)

https://travis-ci.org/traversaro/robotology-superbuild/jobs/314834847

@drdanz Any idea? I will probably just use CMake 3.5 in Travis, but I want to let you know about this.

CMake 3.5 fails if ROBOTOLOGY_USES_PYTHON option is enabled

The following CMakeError is thrown while compiling the superbuild with the ROBOTOLOGY_USES_PYTHON cmake option is turned ON

Unknown CMake command "swig_add_library". 

On investigation with @traversaro it was noted that the swig_add_library macro is available in the UseSWIG.cmake only, starting from cmake version 3.8.2, but ycm handles version only until 3.7

YARP compilation failure in Travis

In file included from /home/travis/build/traversaro/robotology-superbuild/robotology/YARP/src/libYARP_OS/src/Companion.cpp:7:
In file included from /home/travis/build/traversaro/robotology-superbuild/robotology/YARP/src/libYARP_OS/include/yarp/os/impl/Companion.h:15:
/home/travis/build/traversaro/robotology-superbuild/robotology/YARP/src/libYARP_OS/include/yarp/os/impl/PlatformMap.h:22:48: error: redefinition of 'ACE_Equal_To<std::string>'
class __attribute__ ((visibility ("default"))) ACE_Equal_To<std::string>
                                               ^~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/ace/Functor_String.h:86:47: note: previous definition is here
class __attribute__ ((visibility("default"))) ACE_Equal_To<std::string>
                                              ^
In file included from /home/travis/build/traversaro/robotology-superbuild/robotology/YARP/src/libYARP_OS/src/Companion.cpp:7:
In file included from /home/travis/build/traversaro/robotology-superbuild/robotology/YARP/src/libYARP_OS/include/yarp/os/impl/Companion.h:15:
/home/travis/build/traversaro/robotology-superbuild/robotology/YARP/src/libYARP_OS/include/yarp/os/impl/PlatformMap.h:31:48: error: redefinition of 'ACE_Hash<std::string>'
class __attribute__ ((visibility ("default"))) ACE_Hash<std::string>
                                               ^~~~~~~~~~~~~~~~~~~~~
/usr/include/ace/Functor_String.h:98:47: note: previous definition is here
class __attribute__ ((visibility("default"))) ACE_Hash<std::string>
                                              ^
In file included from /home/travis/build/traversaro/robotology-superbuild/robotology/YARP/src/libYARP_OS/src/Companion.cpp:7:
In file included from /home/travis/build/traversaro/robotology-superbuild/robotology/YARP/src/libYARP_OS/include/yarp/os/impl/Companion.h:15:
/home/travis/build/traversaro/robotology-superbuild/robotology/YARP/src/libYARP_OS/include/yarp/os/impl/PlatformMap.h:50:48: error: redefinition of 'ACE_Less_Than<std::string>'
class __attribute__ ((visibility ("default"))) ACE_Less_Than<std::string>
                                               ^~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/ace/Functor_String.h:111:47: note: previous definition is here
class __attribute__ ((visibility("default"))) ACE_Less_Than<std::string>
                                              ^
3 errors generated.
make[5]: *** [src/libYARP_OS/CMakeFiles/YARP_OS.dir/src/Companion.cpp.o] Error 1
make[4]: *** [src/libYARP_OS/CMakeFiles/YARP_OS.dir/all] Error 2
make[3]: *** [all] Error 2
make[2]: *** [robotology/YARP/CMakeFiles/YCMStamp/YARP-build] Error 2
make[1]: *** [CMakeFiles/YARP.dir/all] Error 2
make: *** [all] Error 2

See https://travis-ci.org/traversaro/robotology-superbuild/jobs/315414081 .
cc @drdanz Any idea?

Complete the documentation of the ROBOTOLOGY_USES_PYTHON option

The ROBOTOLOGY_USES_PYTHON is not officially tested and documented, but has been around for some time. This issue is about supporting it "officially" and document it.

Recap as of March 2020:

  • Make sure that the correct Python is found (see #364)
  • Add documentation of the ROBOTOLOGY_USES_PYTHON option in the README, following the structure of other ROBOTOLOGY_USES_* options
  • Make sure that the option is tested on all the platforms for which it is document to work in README
  • Once the ROBOTOLOGY_USES_PYTHON is documented, we can remove the mark_as_advanced.

Specify a desired version in YCMBootstrap

In the existing superbuild, we routinely change the YCM_TAG option to specify that we require some newer version of ycm to build the superbuild. However, when we check if a YCM is available in the system, we do not check for its version, so it often happens that the superbuild is not working because the user has an outdated ycm installed in his system.

This is similar to the problem that applies to generic projects in the superbuild: robotology-legacy/codyco-superbuild#161 .

Enabling ROBOTOLOGY_USES_OCTAVE throws cmake error

The following error is thrown while configuring cmake for yarp-matlab-bindings in core and iDyntree in dynamics

Could NOT find Octave (missing: OCTAVE_ROOT_DIR OCTAVE_INCLUDE_DIRS OCTAVE_LIBRARIES)

Available Octave version on the system is 4.0.0

I also noticed that YCM from another super-build directory is being used to configure the necessary setup. However, since the options USE_SYSTEM_$PROJECT$ are all disabled, the desired cloning, compiling and installing is performed.

Missing folders in "../robotology-superbuild/build/install/"

I followed the instructions in the README.md and seems everything went fine, I do not have errors during the compilation. But when I tried to configure my environment, I found out that the following folders have not been installed and do not know why:

../robotology-superbuild/build/install/lib
../robotology-superbuild/build/install/share/yarp
../robotology-superbuild/build/install/share/iCub

Installing system dependencies on Windows using vcpkg

At the moment, in the official documentation we recommend to install most of the "System Dependencies" on Windows using the YARP and iCub dependency installers.

However, expert users may prefer to use vcpkg. As already discussed in the past, I think in the long term the most maintainable solution is to generated our installer from vcpkg packages (see robotology-playground/vcpkg-cpack#2 for a related discussion). However, until we find the time to work on that, I don't think vcpkg is suitable to be used by every user, due to the long time necessary for the compilation of some packages (qt5).

For the time being, I will just keep on this issue the vcpkg package that provide the necessary dependencies for each superbuild profile.
Note: use --triplet x86-windows if you want to build packages for 32 bit.

ROBOTOLOGY_ENABLE_CORE

 ./vcpkg install --triplet x64-windows ace gsl eigen3 opencv freeglut ode sdl1 sdl2 qt5

Note: qt5 now is split in several smaller subpackages, we should identify the one that are actually necessary for YARP/iCub GUIs.

ROBOTOLOGY_ENABLE_IHMC

 ./vcpkg install --triplet x64-windows asio

ROBOTOLOGY_USES_GAZEBO

Work in progress at https://github.com/traversaro/gazebo-superbuild#windows .

WBToolbox not building in robotology-superbuild

Description

When compiling the superbuild, I get the error:

...
    cd /Users/nunoguedelha/dev/robotology-superbuild/robotology/WBToolbox
    export LANG=en_US.US-ASCII
    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x c++ -arch x86_64 -fmessage-length=0 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit=0 -Wno-trigraphs -fpascal-strings -O3 -Wno-missing-field-initializers -Wno-missing-prototypes -Wno-return-type -Wno-non-virtual-dtor -Wno-overloaded-virtual -Wno-exit-time-destructors -Wno-missing-braces -Wparentheses -Wswitch -Wno-unused-function -Wno-unused-label -Wno-unused-parameter -Wno-unused-variable -Wunused-value -Wno-empty-body -Wno-uninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wno-constant-conversion -Wno-int-conversion -Wno-bool-conversion -Wno-enum-conversion -Wno-float-conversion -Wno-non-literal-null-conversion -Wno-objc-literal-conversion -Wno-shorten-64-to-32 -Wno-newline-eof -Wno-c++11-extensions -DCMAKE_INTDIR=\"Release\" -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -fasm-blocks -fstrict-aliasing -Wdeprecated-declarations -Winvalid-offsetof -mmacosx-version-min=10.12 -Wno-sign-conversion -Wno-infinite-recursion -Wno-move -Wno-comma -Wno-block-capture-autoreleasing -Wno-strict-prototypes -Wno-range-loop-analysis -I/Users/nunoguedelha/dev/robotology-superbuild/build/robotology/WBToolbox/lib/Release/include -I/Users/nunoguedelha/dev/robotology-superbuild/robotology/WBToolbox/toolbox/autogenerated/include -I/Users/nunoguedelha/dev/robotology-superbuild/build/robotology/WBToolbox/toolbox/autogenerated/WB-Toolbox.build/Release/ClockServer.build/DerivedSources/x86_64 -I/Users/nunoguedelha/dev/robotology-superbuild/build/robotology/WBToolbox/toolbox/autogenerated/WB-Toolbox.build/Release/ClockServer.build/DerivedSources -Wmost -Wno-four-char-constants -Wno-unknown-pragmas -F/Users/nunoguedelha/dev/robotology-superbuild/build/robotology/WBToolbox/lib/Release -DNDEBUG -fPIC -std=gnu++11 -MMD -MT dependencies -MF /Users/nunoguedelha/dev/robotology-superbuild/build/robotology/WBToolbox/toolbox/autogenerated/WB-Toolbox.build/Release/ClockServer.build/Objects-normal/x86_64/ClockServer.d --serialize-diagnostics /Users/nunoguedelha/dev/robotology-superbuild/build/robotology/WBToolbox/toolbox/autogenerated/WB-Toolbox.build/Release/ClockServer.build/Objects-normal/x86_64/ClockServer.dia -c /Users/nunoguedelha/dev/robotology-superbuild/robotology/WBToolbox/toolbox/autogenerated/src/thrift/ClockServer.cpp -o /Users/nunoguedelha/dev/robotology-superbuild/build/robotology/WBToolbox/toolbox/autogenerated/WB-Toolbox.build/Release/ClockServer.build/Objects-normal/x86_64/ClockServer.o
In file included from /Users/nunoguedelha/dev/robotology-superbuild/robotology/WBToolbox/toolbox/autogenerated/src/thrift/ClockServer.cpp:4:
/Users/nunoguedelha/dev/robotology-superbuild/robotology/WBToolbox/toolbox/autogenerated/include/thrift/ClockServer.h:7:10: fatal error: 'yarp/os/Wire.h' file not found
#include <yarp/os/Wire.h>
         ^~~~~~~~~~~~~~~~
1 error generated.

** BUILD FAILED **

So, the header file yarp/os/Wire.h can't be found but it is there, in .../robotology-superbuild/build/install folder.

Analysis

The include path -isystem <robotology-superbuild-root>/build/install/include is missing in the compile command. This sould be due to some wrong configuration in the cmake files of WBToolbox imported repo.

Links nice to have in the robotology-superbuild ROBOTOLOGY_ENABLE_DYNAMICS documentation

As the robotology-superbuild is often the first entry point for users interested in robotology software, it would be nice to have an easy entry point (i.e. github README or FAQs) for users interested in the following use cases (this should be just links to project-specific docs):

  • Use the simulink balancing controller using the Gazebo simulator,
  • Use the simulink balancing controller on the real robot,
  • Use the C++-generated balancing controller using the Gazebo simulator,
  • Use the C++-generated balancing controller using the real robot .
  • How to implement a whole-body controller (see vvv-school tutorials)
  • How to go from a CAD model to a simulation using gazebo-yarp-plugins
  • How to properly write a CMake build system for a library or a program

See robotology-legacy/codyco-superbuild#69 .

Debug prints

While configuring the superbuild, I see this prints:

YCM: _dep_component_set = 1, _dep_component = core
RTF: _dep_component_set = 1, _dep_component = core
YARP: _dep_component_set = 1, _dep_component = core
YARP: _dep_component_set = 1, _dep_component = core
ICUB: _dep_component_set = 1, _dep_component = iCub
YARP: _dep_component_set = 1, _dep_component = core
ICUB: _dep_component_set = 1, _dep_component = iCub
iDynTree: _dep_component_set = 1, _dep_component = dynamics
wholeBodyInterface: _dep_component_set = 1, _dep_component = dynamics
YARP: _dep_component_set = 1, _dep_component = core
ICUB: _dep_component_set = 1, _dep_component = iCub
iDynTree: _dep_component_set = 1, _dep_component = dynamics
wholeBodyInterface: _dep_component_set = 1, _dep_component = dynamics
yarpWholeBodyInterface: _dep_component_set = 1, _dep_component = dynamics

they are probably leftovers YCM debug prints.

Clean WB-Toolbox dependencies

The 3.0 release of WB-Toolbox dropped the wholeBodyInterface and yarpWholeBodyInterface dependencies. They can be removed from the superbuild.

iCub_SIM not found

I have tried to install the robotology-superbuild in Ubuntu 16.04 with the standard configuration, and following the Installation instructions. YARP was working correctly, while iCub_SIM was not found.

It turned out that the package libsdl1.2-dev was missing in the dependencies. I have installed the missing package and rebuilt ICUB, but again YARP works fine, while when I run ICub_SIM I get the error:

iCub_SIM: error while loading shared libraries: libYARP_dev.so.1: cannot open shared object file: No such file or directory

Add icub-tests

I think the icub-tests repository should be added to the superbuild, but I am not sure if it should be in the CORE profile (i.e. enabled by default). Any idea about the strategy on how to include it?

paramHelpConfig missing

When I try to compile the superbuild with ROBOTOLOGY_ENABLE_DYNAMICS option the following error occurs

Could not find a package configuration file provided by "paramHelp"
  (requested version 0.0.3) with any of the following names:

    paramHelpConfig.cmake
    paramhelp-config.cmake

  Add the installation prefix of "paramHelp" to CMAKE_PREFIX_PATH or set
  "paramHelp_DIR" to a directory containing one of the above files.  If
  "paramHelp" provides a separate development package or SDK, be sure it has
  been installed.

Superbuild finds its own subproject components on Ubuntu if <package>_DIR env variables are defined

icub@icub-head:/usr/local/src/robot/robotology-superbuild/build$ make
-- YCM not found. Bootstrapping it.
-- Downloading YCMEPHelper.cmake - Attempt 1 of 3
-- Downloading YCMEPHelper.cmake - SUCCESS
-- Downloading StyleGITHUB.cmake - Attempt 1 of 3
-- Downloading StyleGITHUB.cmake - SUCCESS
-- Performing download step (git clone) for 'YCM'
-- Performing update step for 'YCM'
-- Performing configure step for 'YCM'
-- Performing uninstall step for 'YCM'
-- Performing build step for 'YCM'
-- Performing install step for 'YCM'
-- Found YCM: /usr/local/src/robot/robotology-superbuild/build/install/share/YCM (found version "0.5.1.20171220.1+gite9bfa39")
-- Package RTF not found. Will be downloaded and built.
-- Using iCub from install
-- Package iDynTree not found. Will be downloaded and built.
-- Package wholeBodyInterface not found. Will be downloaded and built.
-- Package yarpWholeBodyInterface not found. Will be downloaded and built.
-- Package codyco-modules not found. Will be downloaded and built.
CMake Deprecation Warning at build/install/lib/cmake/YARP/YARPConfig.cmake:272 (message):
  The YARP_MODULE_PATH variable is deprecated.  CMake find package modules
  are now in YCM.
Call Stack (most recent call first):
  build/install/lib/ICUBcontrib/ICUBcontribConfig.cmake:9999 (_yarp_module_path_is_deprecated)
  build/install/share/YCM/modules/FindOrBuildPackage.cmake:180 (find_package)
  cmake/Buildrobots-configuration.cmake:9 (find_or_build_package)
  build/install/share/YCM/modules/FindOrBuildPackage.cmake:235 (include)
  CMakeLists.txt:152 (find_or_build_package)


CMake Error at build/install/lib/ICUBcontrib/ICUBcontribConfig.cmake:12 (include):
  include could not find load file:

    YarpInstallationHelpers
Call Stack (most recent call first):
  build/install/share/YCM/modules/FindOrBuildPackage.cmake:180 (find_package)
  cmake/Buildrobots-configuration.cmake:9 (find_or_build_package)
  build/install/share/YCM/modules/FindOrBuildPackage.cmake:235 (include)
  CMakeLists.txt:152 (find_or_build_package)


CMake Deprecation Warning at build/install/lib/cmake/YARP/YARPConfig.cmake:272 (message):
  The YARP_MODULE_PATH variable is deprecated.  CMake find package modules
  are now in YCM.
Call Stack (most recent call first):
  build/install/lib/ICUBcontrib/ICUBcontribConfig.cmake:9999 (_yarp_module_path_is_deprecated)
  build/install/share/YCM/modules/FindOrBuildPackage.cmake:287 (find_package)
  cmake/Buildrobots-configuration.cmake:9 (find_or_build_package)
  build/install/share/YCM/modules/FindOrBuildPackage.cmake:235 (include)
  CMakeLists.txt:152 (find_or_build_package)


CMake Error at build/install/lib/ICUBcontrib/ICUBcontribConfig.cmake:12 (include):
  include could not find load file:

    YarpInstallationHelpers
Call Stack (most recent call first):
  build/install/share/YCM/modules/FindOrBuildPackage.cmake:287 (find_package)
  cmake/Buildrobots-configuration.cmake:9 (find_or_build_package)
  build/install/share/YCM/modules/FindOrBuildPackage.cmake:235 (include)
  CMakeLists.txt:152 (find_or_build_package)


-- Package robots-configuration not found. Will be downloaded and built.
-- 
-- The following RUNTIME packages have been found:

 * Git

-- The following OPTIONAL packages have been found:

 * ICUB
 * ICUBcontrib

-- The following REQUIRED packages have been found:

 * YARP_dev
 * YARP_conf
 * YARP_OS
 * YARP_sig
 * YARP_math
 * YARP

-- The following OPTIONAL packages have not been found:

 * RTF
 * iDynTree
 * codyco-modules
 * wholeBodyInterface
 * yarpWholeBodyInterface
 * robots-configuration

-- The following RECOMMENDED packages have not been found:

 * YCM (required version >= 0.8.1) , A collection of CMake modules and utilities for YARP and friends , <https://github.com/robotology/ycm>
   Used by the build system

-- Configuring incomplete, errors occurred!
See also "/usr/local/src/robot/robotology-superbuild/build/CMakeFiles/CMakeOutput.log".
Makefile:1222: recipe for target 'cmake_check_build_system' failed
make: *** [cmake_check_build_system] Error 1

Cleanup usage of CMAKE_ARGS and CMAKE_CACHE_ARGS in Build**.cmake files

It is necessary to cleanup the usage of the CMAKE_ARGS, CMAKE_CACHE_ARGS and CMAKE_DEFAULT_CACHE_ARGS in the calls to ycm_ep_helper in Build***.cmake files.

Back in ~2014, I remember that we always had CMAKE_CACHE_ARGS, but then we started adding subproject CMake options that depended on superbuild options, and so we had problem when switching this option on and off that the relative change was not correctly propagated to the subproject (as the initial cache was already populated, see robotology/ycm-cmake-modules#22 and robotology-legacy/codyco-superbuild#5). From that point, we basically randomly used CMAKE_ARGS and CMAKE_CACHE_ARGS until we reached a configuration that was working for most users.

Given the discussion in #67 (comment) and in #68 (comment), I think it make sense to review all existing Build***.cmake files to make sure that:

  • CMAKE_CACHE_DEFAULT_ARGS can be used with the ExternalProject fork in YCM,
  • CMAKE_ARGS and CMAKE_CACHE_ARGS or is only used for subproject options that depend on superbuild options,
  • CMAKE_CACHE_DEFAULT_ARGS is used for all other variables

A more corner-case but still typical use of CMAKE_ARGS is to make sure that a new modification to the Build***.cmake is also propagated correctly to all existing superbuild installations.

Port the README to the separate documentation

With the great work of @traversaro, the README has reached a really good status. Too good I'd say to stay in the README file. There are so many subsections and levels that the readability in my opinion is affected.

I'd suggest to keep a minor description in the README and port the instructions in the project's Wiki, where it can be split in a better way.

No formula for ipopt when following macOS installation procedure

When following the instruction for installing the superbuild for macOS, it is suggested to install the system dependencies by using brew and launching the following

brew install ace eigen cmake boost tinyxml swig qt5 gsl pkg-config jpeg sqlite readline tinyxml ipopt

However, there is no available formula for ipopt, i.e.

brew install ace eigen cmake boost tinyxml swig qt5 gsl pkg-config jpeg sqlite readline tinyxml ipopt
Error: No available formula with the name "ipopt" 
==> Searching for a previously deleted formula (in the last month)...
Warning: homebrew/core is shallow clone. To get complete history run:
  git -C "$(brew --repo homebrew/core)" fetch --unshallow

Error: No previously deleted formula found.
==> Searching for similarly named formulae...
==> Searching local taps...
Error: No similarly named formulae found.
==> Searching taps...
==> Searching taps on GitHub...
Error: No formulae found in taps.

See this issue for further details

As suggested by @traversaro, ipopt can be installed by launching

brew install dartsim/dart/ipopt

The README should be corrected accordingly

RFC: new robotology-superbuild

Hi everyone,
we (DIC/loc2) had to cleanup the good old codyco-superbuild, as the CoDyCo project has finally ended in April 2017 .
As the in the past few months we had a few discussion related to "we would really need a general superbuild for the software developed in the iCub Facility", I structured the new superbuild in a way that it can be easily used for all software developed in the robotology repository. I named it robotology-superbuild as this seems to me the most natural name. I already discussed with @liesrock that previously administered a similarly-named superbuild that actually contained only ADVR-mantained software, and he told me he is ok with this name. I opened the repo on my personal profile as https://github.com/robotology-playground/robotology-superbuild is already taken, but as soon as it is working

The key concept is the "profile" (if you have a better name please propose one), that is a group of software projects that a given user is interested in install (as I would imagine that the average user is not interested in installing all the software contained in the robotology organization).

At the moment the supported profile are:

  • Core : the "core" software (RTF, YARP, ICUB, ..).
  • Dynamics: the software used by DIC/loc2 researchers, including Simulink-based controllers.

I already added support for some profiles that could be useful:

  • IOL : everything that is necessary to run the IOL demo (https://github.com/robotology/iol).
  • Grasping: everything that is necessary to run the icub-grasp-demo (https://github.com/robotology/icub-grasp-demo ).
  • ICUB_ROBOT_CAN : everything that is necessary to run the yarprobotinterface on the pc104 of a CAN-based iCub .
  • ICUB_ROBOT_ETH : everything that is necessary to run the yarprobotinterface on the pc104/icub-head of a ETH-based iCub .
  • R1_ROBOT : everything that is necessary to run the yarprobotinterface on the computers of the R1 .

However, all this profiles are hidden (i.e. they are not mentioned in the documentation, and the relative cmake options are marked as advanced) unless a maintainer (i.e. somebody that is in charge to make sure that the superbuild with those components enabled works as intended) is identified for this components.

There are a few activities that I think could be beneficial related to a iCub Facility-superbuild, such as:

  • Port the instructions to compile YARP and ICUB on the pc104/icub-head (http://wiki.icub.org/wiki/Compilation_on_the_pc104 and robotology/icub-main#456) to use the superbuild with appropriate settings, train all the people involved in the maintenance of the robot and eventually migrate the robot setups to use the superbuild. This will simplify refactoring the contents of the Core repository in the future.
  • Officially support the profiles related to grasping/vision/learning, finding suitable mantainers.
  • Provide a vcpkg-based installer for all the dependencies (including vision/learning one) of software in the superbuild, making sure that the superbuild can be easily installed even on Windows.

However, nothing of this is currently planned, and it will be carried on only if there is interest/commitment from the interested people.

How to handle the devel branches?

In the last two years, more and more repositories in the robotology organization have started to use the YARP model of having two branches, master only for bug fixes and devel for active developement. It is also quite common that the devel branch of a given package is only compatible with the devel branch of its robotology dependencies.

At the moment, the workflow to deal with "devel" branches is quite cumbersome, and is documented here: https://github.com/robotology/robotology-superbuild#handling-the-devel-branch .

Anyone has any idea on how to streamline this process?

Some pointers:

cc @diegoferigo @S-Dafarra @gabrielenava

Test different configurations and linux distros

One of the main targets of a superbuild is to compile flawlessly on many system configurations. Unfortunately the variability of dependencies and their versions is really wide among distributions, and after changes in handled projects it is easy to forget testing all the supported distros (even the oldest).

In my opinion this is one of the cases where docker features are exploited at their best. I'm open for a discussion on how to include its support to our Travis pipeline.

@traversaro

Test usage of robotology-superbuild to compile all necessary software on the real robot

robotology-superbuild has been used for a long time on the real robot for compiling dynamics-related software, especially on the iCub robots iCubGenova02 and iCubGenova04 . However, is has always been used just to compile dynamics-specific software, such as iDynTree and the WB-Toolbox . In this issue we will track the effort necessary to use it to manage all the software used in the robot, including YARP and ICUB .

Note: this is an experimental protocol that will be tested for now only on iCubGenova04. If you are a user of any other iCub, please stick to the canonical installation layout described in http://wiki.icub.org/wiki/The_Linux_on_the_pc104 and http://wiki.icub.org/wiki/ICub_server_laptop_installation_instructions.

Broken compilation on ubuntu

I cloned therobotology-superbuild on my laptop and I tried to compile it in a custom configuration:

Options:

ROBOTOLOGY_ENABLE_DYNAMICS = ON
ROBOTOLOGY_USES_MATLAB = ON

Repos in devel branch

  • gazebo-yarp-plugins
  • yarp-matlab-bindings
  • ICUB
  • YARP
  • iDyntree
  • codyco-modules

I got the following error during compilation:

In file included from /home/gnava/Software/github/robotology/robotology-superbuild/build/install/include/yarp/os/api.h:13:0,
                 from /home/gnava/Software/github/robotology/robotology-superbuild/build/install/include/yarp/os/ConstString.h:13,
                 from /home/gnava/Software/github/robotology/robotology-superbuild/build/install/include/yarp/os/ContactStyle.h:13,
                 from /home/gnava/Software/github/robotology/robotology-superbuild/build/install/include/yarp/os/Network.h:13,
                 from /home/gnava/Software/github/robotology/robotology-superbuild/robotology/GazeboYARPPlugins/plugins/camera/include/gazebo/Camera.hh:13,
                 from /home/gnava/Software/github/robotology/robotology-superbuild/robotology/GazeboYARPPlugins/plugins/camera/src/Camera.cc:8:
/home/gnava/Software/github/robotology/robotology-superbuild/build/install/include/yarp/os/Stamp.h:96:7: error: expected identifier before ‘__attribute__’
 class YARP_OS_DEPRECATED_API Stamped
       ^
In file included from /home/gnava/Software/github/robotology/robotology-superbuild/robotology/GazeboYARPPlugins/plugins/camera/include/yarp/dev/CameraDriver.h:12:0,
                 from /home/gnava/Software/github/robotology/robotology-superbuild/robotology/GazeboYARPPlugins/plugins/camera/src/Camera.cc:9:
/home/gnava/Software/github/robotology/robotology-superbuild/build/install/include/yarp/os/Stamp.h:98:1: error: expected primary-expression before ‘public’
 public:
 ^
/home/gnava/Software/github/robotology/robotology-superbuild/build/install/include/yarp/os/Stamp.h:98:1: error: expected ‘}’ before ‘public’
/home/gnava/Software/github/robotology/robotology-superbuild/build/install/include/yarp/os/Stamp.h:98:1: error: expected ‘,’ or ‘;’ before ‘public’
/home/gnava/Software/github/robotology/robotology-superbuild/build/install/include/yarp/os/Stamp.h:108:30: error: ‘virtual’ outside class declaration
     virtual Stamp getStamp() const = 0;
                              ^
/home/gnava/Software/github/robotology/robotology-superbuild/build/install/include/yarp/os/Stamp.h:108:30: error: non-member function ‘yarp::os::Stamp yarp::os::getStamp()’ cannot have cv-qualifier
/home/gnava/Software/github/robotology/robotology-superbuild/build/install/include/yarp/os/Stamp.h:108:38: error: function ‘yarp::os::Stamp yarp::os::getStamp()’ is initialized like a variable
     virtual Stamp getStamp() const = 0;
                                      ^
/home/gnava/Software/github/robotology/robotology-superbuild/build/install/include/yarp/os/Stamp.h:112:1: error: expected declaration before ‘}’ token
 } // namespace yarp
 ^
plugins/camera/CMakeFiles/gazebo_yarp_camera.dir/build.make:62: recipe for target 'plugins/camera/CMakeFiles/gazebo_yarp_camera.dir/src/Camera.cc.o' failed
make[5]: *** [plugins/camera/CMakeFiles/gazebo_yarp_camera.dir/src/Camera.cc.o] Error 1
CMakeFiles/Makefile2:408: recipe for target 'plugins/camera/CMakeFiles/gazebo_yarp_camera.dir/all' failed
make[4]: *** [plugins/camera/CMakeFiles/gazebo_yarp_camera.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make[3]: *** [all] Error 2
CMakeFiles/GazeboYARPPlugins.dir/build.make:107: recipe for target 'robotology/GazeboYARPPlugins/CMakeFiles/YCMStamp/GazeboYARPPlugins-build' failed
make[2]: *** [robotology/GazeboYARPPlugins/CMakeFiles/YCMStamp/GazeboYARPPlugins-build] Error 2
CMakeFiles/Makefile2:1882: recipe for target 'CMakeFiles/GazeboYARPPlugins.dir/all' failed
make[1]: *** [CMakeFiles/GazeboYARPPlugins.dir/all] Error 2
Makefile:94: recipe for target 'all' failed

Cleanup MATLAB docs

Dealing with all the different variations of the Matlab install on users computer is typically the biggest bottleneck for new users installing the superbuild, as we saw with @gabrielenava and @ahmadgazar .

Things to cleanup:

  • Clarify how the CMake subprojects of the superbuild are actually finding Matlab. In particular, if the robotology is not able to find Matlab, the user has no guidance on how to setup its system to make sure that matlab is found. As of CMake 3.10 the FindMatlab.cmake is not checking any env variable such as Matlab_ROOT_DIR or MATLAB_DIR, the only reliable way to get CMake to detect matlab is to ensure that this call to find_program is able to find the matlab program: https://github.com/Kitware/CMake/blob/v3.10.2/Modules/FindMatlab.cmake#L1035 . To make sure that find_program finds matlab, it is possible to check the search policy of find_program in CMake's docs : https://cmake.org/cmake/help/v3.8/command/find_program.html?highlight=i . In particular, adding (at least temporary) the directory in which matlab is contained in PATH or CMAKE_PROGRAM_PATH should do the trick.
  • Mention all the LD_PRELOAD problem, at least pointing to some exhaustive documentation on how to deal with it (see #64).

Ubuntu 18.04 support

On April the 26th, the new Ubuntu LTS 18.04 will be released. It would be extremely useful if someone could try to run the robotology-superbuild with as many documented profile or dependencies options.

Hopefully everything should work fine, but if this will not be the case, it would be good to report any issue to the appropriate subproject or fix any documentation issue in the robotology-superbuild itself.

Even if you do not use Ubuntu 18.04 on your machine, testing this using the bionic Docker image should be trivial.

Any help on this would be extremely welcome.

Using Ninja generator fails with bad $-escape

The full error is the following:

$ cmake --build .
ninja: error: build.ninja:477: bad $-escape (literal $ must be written as $$)

The error is generated by variables such as $(COLOR) which should be $$(COLOR) or ${COLOR}. This issue is just a reminder if any of you encounter this issue.

Follow the upstream issue at https://gitlab.kitware.com/cmake/cmake/issues/18062.

cc @drdanz do you have any further insight on this? I'm not expert on these CMake edges.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.