Set default of ROBOTOLOGY_PROJECT_TAGS to Custom and fix release problems

[traversaro]

Otherwise ROBOTOLOGY_PROJECT_TAGS_CUSTOM_FILE is ignored, for future reference this is necessary for all the releases/* branches, i.e. #350 is incomplete.

[traversaro]

Actually running this in CI is more complicated then expected. The problem is that in the current GitHub Actions scripts, the ROBOTOLOGY_PROJECT_TAGS is being overridden by the

robotology-superbuild/.github/workflows/ci.yml

Line 117 in 061bfba

cmake -G"${{ matrix.cmake_generator }}" -DROBOTOLOGY_USES_GAZEBO:BOOL=ON -DROBOTOLOGY_USES_OCTAVE:BOOL=ON -DROBOTOLOGY_USES_PYTHON:BOOL=ON -DROBOTOLOGY_ENABLE_ROBOT_TESTING:BOOL=ON -DROBOTOLOGY_ENABLE_DYNAMICS:BOOL=ON -DROBOTOLOGY_ENABLE_HUMAN_DYNAMICS:BOOL=ON -DROBOTOLOGY_ENABLE_ICUB_HEAD:BOOL=ON -DROBOTOLOGY_ENABLE_ICUB_BASIC_DEMOS:BOOL=ON -DNON_INTERACTIVE_BUILD:BOOL=TRUE -DCMAKE_BUILD_TYPE=${{ matrix.build_type }} -DROBOTOLOGY_PROJECT_TAGS=${{ matrix.project_tags }} ..

and

robotology-superbuild/.github/workflows/ci.yml

Line 132 in 061bfba

cmake -A x64 -DCMAKE_TOOLCHAIN_FILE=C:/robotology/vcpkg/scripts/buildsystems/vcpkg.cmake -DROBOTOLOGY_USES_GAZEBO:BOOL=OFF -DROBOTOLOGY_USES_OCTAVE:BOOL=OFF -DROBOTOLOGY_USES_PYTHON:BOOL=OFF -DROBOTOLOGY_ENABLE_ROBOT_TESTING:BOOL=ON -DROBOTOLOGY_ENABLE_DYNAMICS:BOOL=ON -DROBOTOLOGY_ENABLE_HUMAN_DYNAMICS:BOOL=ON -DROBOTOLOGY_ENABLE_ICUB_HEAD:BOOL=ON -DROBOTOLOGY_ENABLE_ICUB_BASIC_DEMOS:BOOL=ON -DNON_INTERACTIVE_BUILD:BOOL=TRUE -DCMAKE_BUILD_TYPE=${{ matrix.build_type }} -DROBOTOLOGY_PROJECT_TAGS=${{ matrix.project_tags }} ..

. Probably the best solution for now is to remove that part in the releases/2020.02 branch, and then think for 2020.05 a more permanent solution.

[traversaro]

Great, the CI is finally failing so it means that is actually running. : )

[traversaro]

Great, the CI is finally failing so it means that is actually running. : )

There was a problem in the icub-gazebo URL, fixed by 2b958f9 .

[traversaro]

Ok, finally some real problems that we did not have on master branches:

2020-02-21T13:20:15.3104374Z D:\a\robotology-superbuild\robotology-superbuild\robotology\human-dynamics-estimation\devices\HumanStateProvider\InverseVelocityKinematics\InverseVelocityKinematics.cpp : fatal error C1128: number of sections exceeded object file format limit: compile with /bigobj [D:\a\robotology-superbuild\robotology-superbuild\build\robotology\human-dynamics-estimation\devices\HumanStateProvider\HumanStateProvider.vcxproj] [D:\a\robotology-superbuild\robotology-superbuild\build\human-dynamics-estimation.vcxproj]

This is due to robotology/human-dynamics-estimation#174 and robotology/human-dynamics-estimation#171 (comment) , and the fix is apparently not provided in v2.0.0. Can we tag a new version v2.0.1 containing this fix? @lrapetti @Yeshasvitvs

2020-02-21T13:15:59.2609392Z   CMake Error at C:/robotology/vcpkg/scripts/buildsystems/vcpkg.cmake:195 (_add_library):
2020-02-21T13:15:59.2609926Z     Target "UnicyclePlanner" links to target "OsqpEigen::OsqpEigen" but the
2020-02-21T13:15:59.2610227Z     target was not found.  Perhaps a find_package() call is missing for an
2020-02-21T13:15:59.2610478Z     IMPORTED target, or an ALIAS target is missing?
2020-02-21T13:15:59.2613476Z   Call Stack (most recent call first):
2020-02-21T13:15:59.2613765Z     CMakeLists.txt:93 (add_library)
2020-02-21T13:15:59.2614189Z   
2020-02-21T13:15:59.2614779Z   
2020-02-21T13:15:59.2615023Z   CMake Error at C:/robotology/vcpkg/scripts/buildsystems/vcpkg.cmake:195 (_add_library):
2020-02-21T13:15:59.2615262Z     Target "UnicyclePlanner" links to target "osqp::osqp" but the target was
2020-02-21T13:15:59.2617445Z     not found.  Perhaps a find_package() call is missing for an IMPORTED
2020-02-21T13:15:59.2617837Z     target, or an ALIAS target is missing?
2020-02-21T13:15:59.2618081Z   Call Stack (most recent call first):
2020-02-21T13:15:59.2618321Z     CMakeLists.txt:93 (add_library)

This is robotology/unicycle-footstep-planner#33 . It has been fixed in iDynTree in robotology/idyntree#642, but the fix is not part of iDynTree v1.0.1 . @traversaro can you please tag a v1.0.2 with this fix?

[traversaro]

@traversaro can you please tag a v1.0.2 with this fix?

Done in robotology/idyntree#650 .

[yeshasvitirupachuri]

@traversaro we updated the master branch with the latest changes in devel following the PR robotology/human-dynamics-estimation#164.

After the CI checks are done, we will tag the master with v2.1.0 as the secondary calibration is more of a new feature than a patch.

@lrapetti

[traversaro]

After the CI checks are done, we will tag the master with v2.1.0 as the secondary calibration is more of a new feature than a patch.

The CI checks seems to have a failure, but related to the deployment of the documentation, not of the library itself, so if you could tag v2.1.0 it would be great.

[traversaro]

After the CI checks are done, we will tag the master with v2.1.0 as the secondary calibration is more of a new feature than a patch.

The CI checks seems to have a failure, but related to the deployment of the documentation, not of the library itself, so if you could tag v2.1.0 it would be great.

fyi @lrapetti @Yeshasvitvs
Note that I already tested that commit in the robotology-superbuild CI with e6c792f, so it should be save to tag it, thanks!

[yeshasvitirupachuri]

@traversaro

https://github.com/robotology/human-dynamics-estimation/releases/tag/v2.1.0

[traversaro]

@traversaro

https://github.com/robotology/human-dynamics-estimation/releases/tag/v2.1.0

Thanks! Just to understand, at the CMake level the version is still 2.0.0 (See https://github.com/robotology/human-dynamics-estimation/blob/269a08c2a282f87da3dad788e31b502ccc542409/CMakeLists.txt#L8) , this is not a big problem, but it may be confusing for downstream projects if they actually want to enforce the dependencny on 2.1.0 and its new features.

[yeshasvitirupachuri]

@traversaro The version of OsqpEigen is updated from v0.4.0 to v0.5.2 for robotology 2020.02 release. However, inside HDE, the version referred to was v0.4.0 https://github.com/robotology/human-dynamics-estimation/blob/v2.1.0/devices/HumanStateProvider/CMakeLists.txt#L7. Didn't this result in any build issues during CI ?

[traversaro]

@traversaro The version of OsqpEigen is updated from v0.4.0 to v0.5.2 for robotology 2020.02 release. However, inside HDE, the version referred to was v0.4.0 https://github.com/robotology/human-dynamics-estimation/blob/v2.1.0/devices/HumanStateProvider/CMakeLists.txt#L7. Didn't this result in any build issues during CI ?

The compatibility rule is defined in OsqpEigen, and in the update from 0.4 to 0.5.2 the compatibility rules has changed to SameMajorVersion in robotology/osqp-eigen@a349543, so if the version requested is 0.4.0, 0.5.2 results as compatible.