Add irrlicht, update vcpkg and install ignition libraries via vcpkg

[traversaro]

irrlicht is used by iDynTree visualizer support, that against my advice several people are using. : )
It is quite a small and self-contained library, so I think it is perfectly safe to add it.

[traversaro]

The build is failing with error:

Starting package 85/83: ode:x64-windows
Building package ode[core]:x64-windows...
Could not locate cached archive: C:\Users\runneradmin\AppData\Local\vcpkg\archives\a3\a3d01d00781f8ef07054183dc4048047f987150f.zip
-- Downloading https://bitbucket.com/odedevs/ode/get/0.16.1.tar.gz...
-- Extracting source C:/robotology/vcpkg/downloads/odedevs-ode-0.16.1.tar.gz
-- Using source at C:/robotology/vcpkg/buildtrees/ode/src/0.16.1-4fa7add51b.clean
-- Configuring x64-windows
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:85 (message):
    Command failed: ninja -v
    Working Directory: C:/robotology/vcpkg/buildtrees/ode/x64-windows-rel/vcpkg-parallel-configure
    Error code: 1
    See logs for more information:
      C:\robotology\vcpkg\buildtrees\ode\config-x64-windows-out.log

Call Stack (most recent call first):
  scripts/cmake/vcpkg_configure_cmake.cmake:312 (vcpkg_execute_required_process)
  ports/ode/portfile.cmake:9 (vcpkg_configure_cmake)
  scripts/ports.cmake:79 (include)

I don't have access to the log, but I guess this may be connected to microsoft/vcpkg#15250 that happens if CMake 3.19.0 or 3.19.1 are used (https://gitlab.kitware.com/cmake/cmake/-/issues/21529).

[traversaro]

Indeed, ti seems that GitHub Action Windows images is using the CMake 3.19.1 at the moment: actions/runner-images#2192 (comment) . In theory vcpkg has its own copy of CMake (see for example microsoft/vcpkg#14716), but if a newer version is found in the system, that one is used, with no way of forcing the use of the internal version (see https://github.com/microsoft/vcpkg/blob/9ddc9173d7858ddb40b2fc0cdc73b529c390ba47/docs/users/config-environment.md#vcpkg_force_system_binaries). In this case the internal version would be 3.18.4 (that was working fine), but we have no way of forcing the use of it. In theory we could find a workaround by deleting the CMake installed by the GitHub Actions image, but in practice is just easier to update vcpkg to a commit after microsoft/vcpkg#14716 so that the internal 3.19.2 is used.

[traversaro]

In theory we could find a workaround by deleting the CMake installed by the GitHub Actions image, but in practice is just easier to update vcpkg to a commit after microsoft/vcpkg#14716 so that the internal 3.19.2 is used.

Done in acc2003 .

[traversaro]

Obviously updating vcpkg broke the Gazebo build.

[traversaro]

Obviously updating vcpkg broke the Gazebo build.

At this point, given that microsoft/vcpkg#11273 was finally merged, let's also add a vcpkg port for ignition-fuel-tools4, so we can install all Gazebo11 dependencies from vcpkg and this should simplify the debug.

[traversaro]

Obviously updating vcpkg broke the Gazebo build.

At this point, given that microsoft/vcpkg#11273 was finally merged, let's also add a vcpkg port for ignition-fuel-tools4, so we can install all Gazebo11 dependencies from vcpkg and this should simplify the debug.

Done in 7c37d1e and cd733a3 .

[traversaro]

The latest Gazebo requires sdformat 9.3, and the version in vcpkg was too old. I bumped it in microsoft/vcpkg#15720 .

[traversaro]

The latest Gazebo requires sdformat 9.3, and the version in vcpkg was too old. I bumped it in microsoft/vcpkg#15720 .

That PR was merged, and I updated the vcpkg version in cff73ec . In ddb892b I also updated the Gazebo version to include the fix gazebosim/gazebo-classic#2862 for compilation against the latest Boost, unfortunately we can't use the 11.3.0 release due to the bug gazebosim/gazebo-classic#2905 that I introduced in it and is only fixed in the latest master commit.

[traversaro]

The job continues to fail, so I modified it to also upload the complete logs as an artifacts. By inspecting the logs (
gazebo-colcon-logs.zip ), it is possible to see that the failure is due to:

C:\robotology\gazebo\src\gazebo\gazebo\rendering\Visual.cc(777,65): error C2660: 'Ogre::MeshManager::getByName': function does not take 1 arguments [C:\robotology\gazebo\build\Gazebo\gazebo\rendering\gazebo_rendering.vcxproj]
C:\robotology\vcpkg\installed\x64-windows\include\OGRE\OgreMeshManager.h(75,17): message : see declaration of 'Ogre::MeshManager::getByName' (compiling source file C:\robotology\gazebo\src\gazebo\gazebo\rendering\Visual.cc) [C:\robotology\gazebo\build\Gazebo\gazebo\rendering\gazebo_rendering.vcxproj]
C:\robotology\gazebo\src\gazebo\gazebo\rendering\Visual.cc(1066,46): error C2664: 'bool Ogre::ResourceManager::resourceExists(Ogre::ResourceHandle)': cannot convert argument 1 from 'std::string' to 'Ogre::ResourceHandle' [C:\robotology\gazebo\build\Gazebo\gazebo\rendering\gazebo_rendering.vcxproj]
C:\robotology\gazebo\src\gazebo\gazebo\rendering\Visual.cc(1067,24): message : No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called [C:\robotology\gazebo\build\Gazebo\gazebo\rendering\gazebo_rendering.vcxproj]
C:\robotology\vcpkg\installed\x64-windows\include\OGRE\OgreResourceManager.h(331,14): message : see declaration of 'Ogre::ResourceManager::resourceExists' (compiling source file C:\robotology\gazebo\src\gazebo\gazebo\rendering\Visual.cc) [C:\robotology\gazebo\build\Gazebo\gazebo\rendering\gazebo_rendering.vcxproj]
C:\robotology\gazebo\src\gazebo\gazebo\rendering\Visual.cc(2077,56): warning C4305: 'argument': truncation from 'double' to 'Ogre::Real' [C:\robotology\gazebo\build\Gazebo\gazebo\rendering\gazebo_rendering.vcxproj]
C:\robotology\gazebo\src\gazebo\gazebo\rendering\Visual.cc(2275,6): error C2664: 'bool Ogre::ResourceManager::resourceExists(Ogre::ResourceHandle)': cannot convert argument 1 from 'std::string' to 'Ogre::ResourceHandle' [C:\robotology\gazebo\build\Gazebo\gazebo\rendering\gazebo_rendering.vcxproj]
C:\robotology\gazebo\src\gazebo\gazebo\rendering\Visual.cc(2275,70): message : No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called [C:\robotology\gazebo\build\Gazebo\gazebo\rendering\gazebo_rendering.vcxproj]
C:\robotology\vcpkg\installed\x64-windows\include\OGRE\OgreResourceManager.h(331,14): message : see declaration of 'Ogre::ResourceManager::resourceExists' (compiling source file C:\robotology\gazebo\src\gazebo\gazebo\rendering\Visual.cc) [C:\robotology\gazebo\build\Gazebo\gazebo\rendering\gazebo_rendering.vcxproj]
  WireBox.cc
  C:\robotology\vcpkg\installed\x64-windows\include\OGRE/OgreVector3.h is deprecated, migrate to Ogre.h
  TBB Warning: tbb/task.h is deprecated. For details, please see Deprecated Features appendix in the TBB reference manual.
C:\robotology\vcpkg\installed\x64-windows\include\boost/bind.hpp(41): message : The practice of declaring the Bind placeholders (_1, _2, ...) in the global namespace is deprecated. Please use <boost/bind/bind.hpp> + using namespace boost::placeholders, or define BOOST_BIND_GLOBAL_PLACEHOLDERS to retain the current behavior. [C:\robotology\gazebo\build\Gazebo\gazebo\rendering\gazebo_rendering.vcxproj]
  C:\robotology\vcpkg\installed\x64-windows\include\OGRE/OgreVector3.h is deprecated, migrate to Ogre.h
C:\robotology\gazebo\src\gazebo\gazebo\rendering\WideAngleCamera.cc(74,31): warning C4101: 'ex': unreferenced local variable [C:\robotology\gazebo\build\Gazebo\gazebo\rendering\gazebo_rendering.vcxproj]
C:\robotology\gazebo\src\gazebo\gazebo\rendering\WideAngleCamera.cc(257,33): warning C4101: 'ex': unreferenced local variable [C:\robotology\gazebo\build\Gazebo\gazebo\rendering\gazebo_rendering.vcxproj]
C:\robotology\gazebo\src\gazebo\gazebo\rendering\WideAngleCamera.cc(329,31): warning C4101: 'ex': unreferenced local variable [C:\robotology\gazebo\build\Gazebo\gazebo\rendering\gazebo_rendering.vcxproj]
C:\robotology\gazebo\src\gazebo\gazebo\rendering\WideAngleCamera.cc(499,41): error C2664: 'void Ogre::ResourceManager::remove(const Ogre::ResourcePtr &)': cannot convert argument 1 from 'const Ogre::String' to 'const Ogre::ResourcePtr &' [C:\robotology\gazebo\build\Gazebo\gazebo\rendering\gazebo_rendering.vcxproj]
C:\robotology\gazebo\src\gazebo\gazebo\rendering\WideAngleCamera.cc(500,50): message : Reason: cannot convert from 'const Ogre::String' to 'const Ogre::ResourcePtr' [C:\robotology\gazebo\build\Gazebo\gazebo\rendering\gazebo_rendering.vcxproj]
C:\robotology\gazebo\src\gazebo\gazebo\rendering\WideAngleCamera.cc(500,48): message : No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called [C:\robotology\gazebo\build\Gazebo\gazebo\rendering\gazebo_rendering.vcxproj]
C:\robotology\vcpkg\installed\x64-windows\include\OGRE\OgreResourceManager.h(278,14): message : see declaration of 'Ogre::ResourceManager::remove' (compiling source file C:\robotology\gazebo\src\gazebo\gazebo\rendering\WideAngleCamera.cc) [C:\robotology\gazebo\build\Gazebo\gazebo\rendering\gazebo_rendering.vcxproj]
C:\robotology\gazebo\src\gazebo\gazebo\rendering\WideAngleCamera.cc(582,59): warning C4305: 'argument': truncation from 'double' to 'Ogre::Real' [C:\robotology\gazebo\build\Gazebo\gazebo\rendering\gazebo_rendering.vcxproj]
  WindowManager.cc
  WrenchVisual.cc

i.e. some kind of API change in the latest OGRE, probably we should have a periodic build that runs with vcpkg master to early catch this problems.

[traversaro]

i.e. some kind of API change in the latest OGRE, probably we should have a periodic build that runs with vcpkg master to early catch this problems.

Interestingly, the last successful build in https://github.com/robotology/robotology-superbuild-dependencies-vcpkg/releases/tag/v0.5.0 was using Ogre 1.12.9#1, while the latest vcpkg has Ogre 1.12.9#4, so it is not a OGRE change, but rather a vcpkg-specific regression.

[traversaro]

i.e. some kind of API change in the latest OGRE, probably we should have a periodic build that runs with vcpkg master to early catch this problems.

Interestingly, the last successful build in https://github.com/robotology/robotology-superbuild-dependencies-vcpkg/releases/tag/v0.5.0 was using Ogre 1.12.9#1, while the latest vcpkg has Ogre 1.12.9#4, so it is not a OGRE change, but rather a vcpkg-specific regression.

The regression is most probably due to microsoft/vcpkg#15194, that changes Ogre to build by default with the strict resource manager, instead of making the strict resource manager opt-in .

[traversaro]

i.e. some kind of API change in the latest OGRE, probably we should have a periodic build that runs with vcpkg master to early catch this problems.

Interestingly, the last successful build in https://github.com/robotology/robotology-superbuild-dependencies-vcpkg/releases/tag/v0.5.0 was using Ogre 1.12.9#1, while the latest vcpkg has Ogre 1.12.9#4, so it is not a OGRE change, but rather a vcpkg-specific regression.

The regression is most probably due to microsoft/vcpkg#15194, that changes Ogre to build by default with the strict resource manager, instead of making the strict resource manager opt-in .

Waiting for the upstream discussion, I enabled all the default features except for strict in 2666dfd .

[traversaro]

It is quite a small and self-contained library, so I think it is perfectly safe to add it.

I really envy your optimism on the possible problems that may arise when we may need to bump vcpkg version, young @traversaro .

[traversaro]

i.e. some kind of API change in the latest OGRE, probably we should have a periodic build that runs with vcpkg master to early catch this problems.

Interestingly, the last successful build in https://github.com/robotology/robotology-superbuild-dependencies-vcpkg/releases/tag/v0.5.0 was using Ogre 1.12.9#1, while the latest vcpkg has Ogre 1.12.9#4, so it is not a OGRE change, but rather a vcpkg-specific regression.

The regression is most probably due to microsoft/vcpkg#15194, that changes Ogre to build by default with the strict resource manager, instead of making the strict resource manager opt-in .

Waiting for the upstream discussion, I enabled all the default features except for strict in 2666dfd .

The workaround worked nice. The problem will be fixed upstream by microsoft/vcpkg#15789, but given that now the CI is working I think we should merge.