add superbuild about codyco-modules HOT 22 CLOSED

Not directly related, but if possible we should add the repository to the dashboard, to provide build testing also on Windows and Mac OS X operating systems.

from codyco-modules.

In fact it is related because the superbuild shoud allow to run tests on the whole repository. Should we do some planning on this?

From: Silvio Traversaro [mailto:[email protected]]
Sent: venerdì 31 gennaio 2014 18:29
To: robotology/codyco
Subject: Re: [codyco] add superbuild (#12)

Not directly related, but if possible we should add the repository to the dashboard, to provide build testing also on Windows and Mac OS X operating systems.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/12#issuecomment-33823213.

from codyco-modules.

A basic version of the codyco superbuild, that install all the dependencies + iDynTree as a separated library + the superbuild branch of the codyco repository (basically like the codyco rovereto branch, but without iDynTree) is currently implemented in repo : https://github.com/robotology-playground/codyco-superbuild

Apparently there are problems in the case YCM is already installed in the machine and is not boostrapped. I committed this different behaviour in the travis_explicit_YCM_installation branch, so it is easy to compare the two outputs in Travis:
https://travis-ci.org/robotology-playground/codyco-superbuild/branches

If the YCM is already installed, the cmake command fails with this output for each dependency not installed in the system:

CMake Error at /usr/share/cmake-2.8/Modules/ExternalProject.cmake:1030 (add_custom_target):
add_custom_target cannot create target "orocos_kdl-NO_DEPENDS" because
another target with the same name already exists. The existing target is a
custom target created in source directory
"/home/travis/build/robotology-playground/codyco-superbuild". See
documentation for policy CMP0002 for more details.
Call Stack (most recent call first):
/usr/local/share/YCM/modules/YCMEPHelper.cmake:544 (externalproject_add_steptargets)
cmake/Buildorocos_kdl.cmake:44 (ycm_ep_helper)
/usr/local/share/YCM/modules/FindOrBuildPackage.cmake:80 (include)
cmake/BuildCoDyCo.cmake:14 (find_or_build_package)
/usr/local/share/YCM/modules/FindOrBuildPackage.cmake:80 (include)
CMakeLists.txt:26 (find_or_build_package)

@drdanz any idea?

from codyco-modules.

@traversaro I just abused of my admin-superpower and pushed a change in your codyco-superbuild travis_explicit_YCM_installation branch in order to test it on travis...
The problem was that the ExternalProject used was the one from CMake. At the moment you need to use YCM_USE_CMAKE_PROPOSED=TRUE because the required changes in some of the CMake files are not merged yet in CMake. I left this flag disabled on purpose, so that if you just need YCM for the FindXXX files you don't have to use the unmerged patches, but you explicitly need to set it for the superbuilds. In the long term, this flag should disappear.

from codyco-modules.

Thanks a lot!

from codyco-modules.

I am progressively migrating all libraries and modules from codyco repository to separated repositories.
The resulting superbuild repository is https://github.com/robotology-playground/codyco-superbuild , and the relative branch in this repository is named "superbuild".

However, there is an issue: I am currently migrating libraries using the template provided in https://gitlab.icub.org/walkman/template-pkg , but this template is depending in 2.8.11, and @drdanz told me that a substantial effort would be necessary to make it compatible with previous version of cmake. Unfortunately, cmake 2.8.11 is not installed in the pc104 of the iCubs that we use for codyco. In particular the situation is:
iCubGenova01 : wheezy pc104 image, cmake 2.8.9
iCubGenova03 : squeeze pc104 image, cmake 2.8.7
@lornat75 do you think is feasible to add cmake 2.8.11 (that is packaged in wheezy-backports ) to the wheezy pc104 ? Or we have to work on removing 2.8.11 dependency ?

from codyco-modules.

I want to continue the migration of CoDyCo repository to separate repository, also to simplify WBI-Toolbox installation #60 .
I will start migrating merging iDynTree modification in master in the separated iDynTree repository ( https://github.com/robotology-playground/iDynTree ), and then I will try to port to a different repository the wholeBodyInterface .

from codyco-modules.

@serena-ivaldi I have some problems with the eigen_unsupported headers necessary by modHelp library. What is original location of this code?

from codyco-modules.

Ok, I found it, apparently the original location is a subdirectory of the eigen repository ( https://bitbucket.org/eigen/eigen/src/e17630a40408243cb1a51ad0fe3a99beb75b7450/unsupported/?at=default ). No build help is provided by default, so integrating it in the superbuild would be tricky. I guess in the meanwhile I will just disable modHelp.

from codyco-modules.

@traversaro What is the problem with these files? They seem to be installed... https://bitbucket.org/eigen/eigen/src/e17630a40408243cb1a51ad0fe3a99beb75b7450/unsupported/Eigen/CMakeLists.txt?at=default

from codyco-modules.

My fault, I presumed this file were not installed because modHelp did not found its dependencies. Turned out instead that the eigen_unsupported files present in codyco extern directory only partially overlap with the eigen_unsupported present in Eigen repository.

We come back to the original question then: @serena-ivaldi what is the original source of the code in extern/eigen_unsupported ?

from codyco-modules.

Ok, the superbuild with all important libraries outside the codyco main repository is finally working ( https://travis-ci.org/robotology-playground/codyco-superbuild ).
@francesco-romano @jeljaik can we try to to merge all available branches so we can proceed in switching to the superbuild branch ?

from codyco-modules.

Super!

From: Silvio Traversaro [mailto:[email protected]]
Sent: martedì 27 maggio 2014 09:56
To: robotology/codyco
Cc: Lorenzo Natale
Subject: [SPAM]Re: [codyco] add superbuild (#12)

Ok, the superbuild with all important libraries outside the codyco main repository is finally working ( https://travis-ci.org/robotology-playground/codyco-superbuild ).
@francesco-romanohttps://github.com/francesco-romano @jeljaikhttps://github.com/jeljaik can we try to to merge all available branches so we can proceed in switching to the superbuild branch ?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/12#issuecomment-44245254.

from codyco-modules.

All the codyco users of which I am aware have switched to building through the superbuild.

We should then execute the last steps in the superbuild transition:

• rename this repository in codyco-components (suggestions for a better name are welcome),
• move codyco-superbuild in the main robotology account,
• link codyco-superbuild in the codyco website as the entry point for software developed in the codyco project.
• a lot of libraries are in the external component, we should move them to more appropriate components.

The main YCM/CMeta shortcoming that our users are reporting is the current lack of XCode support.

from codyco-modules.

codyco-modules?
For me also codyco-components is ok.

I imagine you want to merge the superbuild branch into the master branch of Codyco. Is it possible to branch the master into old-master and keep it around for some time?

from codyco-modules.

#67 done.

from codyco-modules.

@francesco-romano I feel like "module" is yarp-specific, while "component" is used as a more general concept in robotics software engineering literature (see http://pasa.liralab.it/pasapdf/1420_Paikan_etal2014.pdf). For example I feel that a matlab controller is not a "module", but it can be considered a "component".

from codyco-modules.

Another activity related to finally switching to the superbuild is:

• generate the doxygen documentation in http://wiki.icub.org/codyco/dox/html/index.html from the superbuild. @drdanz is the YCM software ready ?

from codyco-modules.

It is not yet integrated in ycm, but you can do it easily like it is done for walkman (see https://gitlab.robotology.eu/walkman/walkman/blob/master/doc/CMakeLists.txt )

from codyco-modules.

I guess in the end codyco-modules is a better choice because we avoid the confusing name clash with YCM components. @drdanz I don't have admin rights on this repository, can you change its name to codyco-modules?

from codyco-modules.

done

from codyco-modules.

The website is updated, and appveyor is failing just because it runs out of time (a lot of time is spent in downloading and extracting icub-main, so I hope we will fit in 30 minutes when we install just our dependencies instead of all icub-main). Therefore I officially declare this issue closed.

from codyco-modules.